VB6 applications crashes when calling C# dll's in production environment

Hi All,
I'm basically .NET developer, not much aware of VB language or VB visual Basic 6.0.
We are trying to work out with VB application running/ using C# dll's. The scenario is like VB exe applications using C# dll's and C# dll's are referenced to VB application using .tlb file.
In development environment(debug mode) the application looks fine and working as expected. But when the same code is put into production environment VB applications are crashing when pointing to C# method calls. We trying to know the reason but application
is getting killed. The issue seems to be sporadic and not able to catch in MsgView(debug tool).
In one more scenario, the VB application is loading C# form and getting data back to VB but when we repeat the same workflow again application is crashing either in 2nd attempt or 3rd attempt.
Has anybody seen such issue? Any input is welcomed.
Thanks,
Shesh

Hi Shesh.ugare
Welcome to MSDN.
I am afraid that these forums donot support VB6, you could refer to this thread:
Where to post your VB 6 questions
If this issue regarding VB6 then you could consider posting this issue in these forums below:
These forums do not support Visual Basic 6, however there are many third-party support sites that do. If you have a VB6-related question please visit these popular forums:
VB Forums
VB City
If not, then you could share more detailed code with us.
Thanks for your understanding.
Regards.
Youjun Tang
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Similar Messages

  • Application crashes when calling DLL built with LabVIEW 2011

    Hello everybody,
    Our application calls DLLs built with LabVIEW 2010 SP1. We installed LabVIEW 2011 and built some DLLs. So far so good. If we start our application and run 2010 DLLs it still works fine. If we run a 2011 DLL just once no error happens, but if we try to run the same 2011 DLL our application crashes reporting the error below. I saved the code for 2010 version and built a DLL and it works fine. Does anyone know why?
    Thank you in advance.
    #Date: Fr, 16. Sep 2011 16:25:25
    #OSName: Microsoft Windows XP Service Pack 3
    #OSVers: 5.1
    #OSBuild: 2600
    #AppName: PasTA
    #Version: 11.0f2 32-bit
    #AppKind: AppLib
    #LabVIEW Base Address: 0x30000000
    16.09.2011 16:25:26.181
    Crash 0x0: Crash caught by NIER
    File Unknown(0) : Crash: Crash caught by NIER
    minidump id: 8a779b3f-51d7-4864-8e4d-6ab0195cd158
    ExceptionCode: 0xC0000005
    N
    0x3072C804 - lvrt <unknown> + 0
    0x3072CBB8 - lvrt <unknown> + 0
    0x7C864191 - KERNEL32 <unknown> + 0
    0x7C83AB50 - KERNEL32 <unknown> + 0
    0x00000000 - PasTA <unknown> + 0
    Attachments:
    error.PNG ‏11 KB

    On that note, you should be able to create DLLs in 2010 and run them with 2011, correct??  In my case, I have a 2010 built DLL (talking to sbRIO), most of the functions work when run in 2011, but a couple of them lock up LabVIEW on the desktop (but not the sbRIO), no lock ups happen with 2010 on the desktop.

  • LabVIEW crashes when calling a dll

    I am trying to call a dll through my LabVIEW program. The dll implements a routine to access an ftp server. When the server is found, everything works as expected. However, if there is a delay in finding the server, LabVIEW throws an error � �An exception occured within the external code called by the Call Library Node�. The detailed error message is attached here.
    The dll function times out after 25 seconds if the server is not found (it returns a signed integer). This error message pops up after roughly 20 seconds.
    The dll was created in VC++ 6.0. It uses standard MFC calls.
    Any information about why this could be happening will be appreciated.
    Thanks.
    Attachments:
    LabVIEW_error.jpg ‏14 KB

    Hi,
    If you call a dll, everything should be just right, or it will crash (if you
    use LV7, you're lucky, most of the times LV stays alive, and only gives a
    message).
    The first thing that should be checked is the calling convention. This
    should probably be "stdcall (API)". This changes the way the parameters and
    return address are pushed to the stack.
    The second point are the parameters. Pointers should be set to pointers,
    LONG to i32 etc. The return parameter can always be set to i32, or to
    nothing.
    My best guess is (since the dll crashes after a while), there should be a
    pointer to a buffer (most likely a cluster, but could be a reference). The
    connection succeeds, and the dll copies the information to the pointer. If
    the pointer is not valid (the memory does
    not belong to LabVIEW), an
    exception is raised.
    Perhaps you can give a function prototype? The prototype is the way to
    start.
    Regards,
    Wiebe.
    "gopinath" wrote in message
    news:[email protected]..
    I am trying to call a dll through my LabVIEW program. The dll
    implements a routine to access an ftp server. When the server is
    found, everything works as expected. However, if there is a delay in
    finding the server, LabVIEW throws an error - "An exception occured
    within the external code called by the Call Library Node". The
    detailed error message is attached here.
    The dll function times out after 25 seconds if the server is not found
    (it returns a signed integer). This error message pops up after
    roughly 20 seconds.
    The dll was created in VC++ 6.0. It uses standard MFC calls.
    Any information about why this could be happening will be appreciated.
    Thanks.

  • Application crashes when calling run_report_object , FRM-93652: The runtime process has terminated abnormally

    I got this error when calling report from my form：
    FRM-93652: The runtime process has terminated abnormally
    Forms Session ID is WLS FORMS.formsapp.101
    Here is the trace dump info :
    Last Trigger  FORM/BLOCK/FIELD: FRM_ACTIVITY_QUEUE.BLK_ACTIVITY_QUEUE.BTN_PRINT
    Last Trigger: WHEN-BUTTON-PRESSED - (In Progress)
    Last Builtin: RUN_REPORT_OBJECT - (In Progress)
    ----- Call Stack Trace -----
    calling              call     entry                argument values in hex
    location             type     point                (? means dubious value)
    siehDumpStackTrace(  call     kgdsdst()            000000000 ? 000000000 ?
    )+104                                              7FFFBF18D110 ? 7FFFBF18D1D8 ?
                                                       7FFFBF1AD130 ? 000000000 ?
    siehjmpterm()+650    call     siehDumpStackTrace(  000000000 ? 2B1668E4EB00 ?
                                  )                    7FFFBF18D110 ? 7FFFBF18D1D8 ?
                                                       7FFFBF1AD130 ? 000000000 ?
    __restore_rt()       call     siehjmpterm()        00000000B ? 2B1668E4EB00 ?
                                                       7FFFBF18D110 ? 7FFFBF18D1D8 ?
                                                       7FFFBF1AD130 ? 000000000 ?
    00002B1660459EB0     signal   __restore_rt()       2B16603F2929 ? 7FFFBF1ADBD8 ?
                                                       000000000 ? 000000002 ?
                                                       000000001 ? 0EBC57ED8 ?
    Anybody knows what might be the cause ?
    Thanks

    Refer to : Oracle Support :  Forms Runtime Crash (FRM-93652) When calling RUN_REPORT_OBJECT in 11g (Doc ID 1306368.1)

  • LabVIEW 2010 crash when calling user32.dll

    Interesting LabVIEW 2010 "feature" I discovered this morning.
    Attached are two identical VIs, one saved in 2010 and one saved in 2009.  These VIs were specifically written to demonstrate the bug I stumbled upon this afternoon.  Each VI when run should allow you to find a specific program (window) open in Microsoft Windows and bring it to the foreground.  It relies on "user32.dll" to perform this operation.  It also allows you to specify the calling convention for the function call.
    In LV 2009, either calling convention works, without error.  However, in LV 2010 the calling convention for the function must be "stdcall (WINAPI)" and not the default "C".  If the calling convention is "C" then LabVIEW crashes and closes without warning.
    If you happen to have both LV 2009 and LV 2010 on your computer, I would love to hear if this phenomenon is duplicated so that I can pinpoint whether the bug is LV 2010 related or is more specific to my personal setup.
    Thanks,
    ~David
    Solved!
    Go to Solution.
    Attachments:
    LV2010 test.vi ‏13 KB
    LV2009 test.vi ‏14 KB

    221113
    Return
    CLFN with the wrong calling convention may siliently crash LabVIEW.
    LabVIEW 8.5 through 2009 could adjust the calling convention at run time if the user selected the wrong option. In 2010 this no longer happens. More information is found in KnowledgeBase 59KB14WI
    Workaround: Use the correct calling convention
    Reported Version: 2010 32-bit
    Resolved Version: N/A
    Added: 07/23/2010
    From 2010 release notes.
    Paul Falkenstein
    Coleman Technologies Inc.
    CLA, CPI, AIA-Vision
    Labview 4.0- 2013, RT, Vision, FPGA

  • Array limitation when calling VB Dll?

    Today I encountered a problem when calling a Visual Basic DLL in Labview 8.2.1
    I had to pass a 3D Array, with one dimension exceeding 30 000. around that array size I ended up with error -2146828282 when calling the Dll.
    The dll was working fine for weeks. So, is there any limition to the array size, which could cause the error?

    Hi sthu,
    Having 30,000 elements in one dimension of an array should not cause any problems by itself.  The maximum number of elements per dimension in an array is (2^31) – 1 as described in the LabVIEW Help for Grouping Data with Arrays and Clusters.  However, this is also dependent upon the memory available in your computer.  If there is not enough memory available in RAM, you might receive an error when passing the array to the DLL.
    I have included a couple links to pages that discuss LabVIEW memory usage and managing large data sets in LabVIEW.  These might help get your application up and running with the larger array sizes.
    VI Memory Usage
    Managing Large Data Sets in LabVIEW
    Donovan

  • I have been using Lightroom 4.4 successfully for over 2 years.  Just tried to import some new photos after a vacation and the application crashes when I click "import" every time.  Tried restarting computer.  Version says it is up to date.

    I have been using Lightroom 4.4 successfully for over 2 years.  Just tried to import some new photos after a vacation and the application crashes when I click "import" every time.  Tried restarting computer.  Version says it is up to date.
    How do I get formal support for this from Adobe?

    Thanks for the response.  The application was crashing.  A Windows message was displayed showing "Lightroom.exe has stopped working", "Windows can check online for a solution the problem.". Etc.
    I just launched Lightroom to check the exact message for this reply - and the Import worked.  It had failed dozens of times before. 

  • Every application crashes when i try to print from it!

    Hello everyone, i have an HP 1012 laserjet and it was working perfectly fine until i installed all the updates for the ILife and everything else that came out earlier this week. Anyone know what is going on??

    I had the same problem as well. All applications crashed when I tried to print.
    I found the solution at http://forums.macrumors.com/showthread.php?t=199701&highlight=printing+crash.
    What I ended up doing was to delete the system's printer drivers (located in Macintosh HD > Library > Printers), then re-installing them from install disk one (optional install). This was suggested by "mad jew" on macrumors, and worked for "EricNau" (using 10.4.6 on iMac G5 17") as well as myself (using 10.4.6 on MBP 17"). Hope it works for you as well.

  • Applications crash when attempting to use network printer

    I just upgraded to Tiger. Now, all applications crash when I attempt to select my network printer (HP laserjet 4600) from the 'File' ->'Print' menu. If the network printer is selected as my default printer, the program closes before the print menu even comes up. However, I can print to this printer if it is my default printer and I use the print icon instead of 'File'->'Print'. I also have a USB printer (Lexmark) which I can print to no problem. I can print to all printers with no problems from Classic applications, and I had no problems printing from either Classic or OS X before upgrading to Tiger. Anyone have any ideas?
    Faris

    Did you run Disk Utility> Repair Permissions after installing the HP driver software? While Repair Permissions may no longer be a useful as it was as a generic troubleshooting step under OS X 10.2.x, it's still essential if you have any third-party software that requires an administrative password to install, especially HP or Adobe software, which are known to trample around placing files with mis-set permissions all over the place.

  • Application crash with error ntdll.dll 00018fea

    Hi,
    I have a problem with my app.exe build.
    I attach a simple code; the Vi open and close a TDM file.
    If I run this Vi in Labview works fine.
    If I build the application.exe on a notebook and I run it I got "Application crash with error ntdll.dll 00018fea".
    I've tried to build the Vi on another Pc Desktop with Labview and here if I run the exe it works fine.
    On the two PC I have LV8.5; the build options are the same.
    On the notebook I've try also to reinstall LV8.5 but I got the same error.
    Can you help me?
    Thanks a lot
    Attachments:
    open tdm.vi ‏33 KB

    MicheleS wrote:
    This morning I've try to put the ntdll.dll of the other PC in the notebook but the problem remain.
    Never ever do that! You were very lucky that both ntdll.dll files were probably the same version so the exchange didn't do much but ntdll.dll is one of the core Windows DLLs were everything goes through that normal applications may access in Windows. A mixup in such a part because of incompatitible ntdll.dll with other system API DLLs might prevent your computer entirely from starting up even in safe mode.
    You should not attempt to ever switch system DLLs between different computers. In such behaviour lays insanity. If you expect a system DLL to be corrupt attempt to do a repair installation instead. Also Windows nowadays has techniques to detect if a system DLL got corrupt and will attempt to repair it, though I guess if ntdll.dll would go belly up it's likely your computer won't even start up.
    Rolf Kalbermatter
    Message Edited by rolfk on 01-14-2008 08:05 AM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • OS 10.3.7 Applications Crash when I do a "save "

    Applications crash when I save documents, so I always save as, and make the file name alittle different. I have fixed and verified permissions, I have trashed preferences, anything else I can do?? this is really getting annoying!
    thanks,
    Tori

    I agree with Roam -- use the new one for a while. Run all your apps to make sure things are cool and work as you desire. In a few months, once you've grown accustomed to the new account, it will be safe to wipe out the old.
    It sounds like there was some corruption in the old account (caches? perms? who knows?) Often these problems can be solved at a more granular level, but if the big and easy answer works, hey, go with that.
    Thanks for the star, BTW.
    Best,
    ~FifthWheel

  • Since upgrading to mavericks my applications crash when i try to use the print dialogue

    since upgrading to mavericks my applications crash when i try to use the print dialogue

    Launch the Console application in any of the following ways:
    ☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)
    ☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.
    ☞ Open LaunchPad. Click Utilities, then Console in the icon grid.
    Step 1
    Make sure the title of the Console window is All Messages. If it isn't, select All Messages from the SYSTEM LOG QUERIES menu on the left. If you don't see that menu, select
    View ▹ Show Log List
    from the menu bar.
    Enter the name of the crashed application or process in the Filter text field. Select the messages from the time of the last crash, if any. Copy them to the Clipboard by pressing the key combination command-C. Paste into a reply to this message (command-V).
    When posting a log extract, be selective. In most cases, a few dozen lines are more than enough.
    Please do not indiscriminately dump thousands of lines from the log into this discussion.
    Important: Some private information, such as your name, may appear in the log. Anonymize before posting.
    Step 2
    In the Console window, look under User Diagnostic Reports (not "Diagnostic and Usage Messages") for crash reports related to the crashed process. The report name starts with the name of the process, and ends with ".crash". Select the most recent report and post the entire contents — again, the text, not a screenshot. In the interest of privacy, I suggest that, before posting, you edit out the “Anonymous UUID,” a long string of letters, numbers, and dashes in the header of the report, if it’s present (it may not be.) Please don’t post other kinds of diagnostic report — they're very long and not helpful.

  • Why does LabView crash when unloading my DLL (reentrant calls)?

    I have written a DLL in Borland Delphi using multiple threads that exports several functions (stdcall). I am using LabVIEW 6i on a WinXP machine.  All functions in the DLL work as expected and return correct values. Everything works fine if I set all Call Library Function Nodes to 'UI-Thread', but as soon as I set one Function Node to 'Reentrant', LabView crashes when I close the VI after it has been executed. I assume the error is caused by the DLL unloading mechanism of LabView. Other C++/Delphi programs using the DLL reentrantly work fine, this only occurs in LabView. In which thread does LabView call FreeLibrary/DLL_PROCESS_DETACH? Has anyone experienced similar problems?

    I have never run into this situation myself, but I do know that calling a multi-threaded DLL or CIN from LabVIEW does depend upon the following criteria:
    If your CIN/DLL doesn't have any global data storage (global variables, files on disk, etc.), AND it doesn't access any hardware (register-level programming) AND it doesn't call any functions/DLLs/Drivers that are thread-unsafe.
    OR
    Your CIN/DLL protects (with semaphores or mutex's) access to those global resources.
    OR
    Your DLL is only called from one, non-reentrant VI
    OR
    Your CIN is only called from one, non-reentrant VI AND you don't access any global resources from CINInit, CINAbort, CINDispose, etc. procedures.
    Hopefully this information can help you out in some way.
    J.R. Allen

  • Extproc crashes when calling external routine

    Can anyone point me to documentation on the causes of extproc.exe crashing when trying to invoke an external procedure? The standard documentation set isn't too helpful for debugging such a problem.
    I have been able to call one external procedure. With two others, I always get an extproc crash with (I believe) an access violation.
    The routines I am trying to call are 3rd-party, so I do not have the ability to view their source, though I do have the list of parameters and the sizes and types.
    What I am hoping to find somewhere is a list of the kinds of things that cause extproc to crash so I can see if any of them are likely culprits in my situation.
    Thanks,
    Bruce Merkle

    Have you tried calling into the dll that CVI calls directly from TestStand?  I am curious to know if this also crashes.
    I am also curious to know if there are any path references in the dll that is called by the CVI program.  If so are they relative, or absolute paths?
    I ask because one of the possibilities is that relative paths are being used to specify a path from the location of the code that is called, and they are not working because the current working directory is being specified by TestStand, and the paths are not relative to the working directory given by TestStand.
    Jensen
    National Instruments
    Applications Engineer

  • Application crashes when using JNI with Jdk 1,2, 1.3 and 1.4

    Hi!
    I have this application that has a GUI written in Java and a file parser written in C. JNI is used to connect these parts together. The problem is that the application only works when I am using jdk 1.1.8 but not when using jdk1.2, jdk1.3 or jdk1.4. I am running the application on a Solaris 8 machine.
    I have not written the application myself but I am going to be working with it from now on. But I have today little knowledge with JNI and I have tried different approaches to solve the problem. For example I have tried to used DDD together with GDB to find out what the problem is but with no luck. When I run the application using jdk1.4 I get the following error when the JVM crashes:
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : 10 occurred at PC=0xFA023164
    Function=Java_Bitmap_setDebug+0x1C
    Library=/usr/u/lal/micview/micview2_1_0_beta1/libBitmapImpl.so
    Current Java thread:
    at Bitmap.setDebug(Native Method)
    at DisplayPanel.loadFile(DisplayPanel.java:396)
    at MicPlot.loadFile(MicPlot.java:1452)
    at MicPlot.loadFile(MicPlot.java:1441)
    at MicPlot.miOpen_Action(MicPlot.java:1267)
    at MicPlot$SymAction.actionPerformed(MicPlot.java:1184)
    at java.awt.MenuItem.processActionEvent(MenuItem.java:588)
    at java.awt.MenuItem.processEvent(MenuItem.java:548)
    at java.awt.MenuComponent.dispatchEventImpl(MenuComponent.java:285)
    at java.awt.MenuComponent.dispatchEvent(MenuComponent.java:273)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:452)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:197)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
    Dynamic libraries:
    0x10000 /opt/java/jdk1.4/bin/java
    0xff360000 /usr/lib/libthread.so.1
    0xff3a0000 /usr/lib/libdl.so.1
    0xff280000 /usr/lib/libc.so.1
    0xff270000 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1
    0xfe000000 /opt/java/j2sdk1.4.1/jre/lib/sparc/client/libjvm.so
    0xff220000 /usr/lib/libCrun.so.1
    0xff200000 /usr/lib/libsocket.so.1
    0xff100000 /usr/lib/libnsl.so.1
    0xff1d0000 /usr/lib/libm.so.1
    0xff250000 /usr/lib/libw.so.1
    0xff0e0000 /usr/lib/libmp.so.2
    0xff0b0000 /opt/java/j2sdk1.4.1/jre/lib/sparc/native_threads/libhpi.so
    0xff080000 /opt/java/j2sdk1.4.1/jre/lib/sparc/libverify.so
    0xff030000 /opt/java/j2sdk1.4.1/jre/lib/sparc/libjava.so
    0xfe7e0000 /opt/java/j2sdk1.4.1/jre/lib/sparc/libzip.so
    0xfe4e0000 /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
    0xedd00000 /opt/java/j2sdk1.4.1/jre/lib/sparc/libawt.so
    0xfc480000 /opt/java/j2sdk1.4.1/jre/lib/sparc/libmlib_image.so
    0xfc410000 /opt/java/j2sdk1.4.1/jre/lib/sparc/motif21/libmawt.so
    0xeda80000 /usr/dt/lib/libXm.so.4
    0xfa090000 /usr/openwin/lib/libXt.so.4
    0xfa3d0000 /usr/openwin/lib/libXext.so.0
    0xfc7e0000 /usr/openwin/lib/libXtst.so.1
    0xed980000 /usr/openwin/lib/libX11.so.4
    0xfa2a0000 /usr/openwin/lib/libdps.so.5
    0xfa3b0000 /usr/openwin/lib/libSM.so.6
    0xfa1d0000 /usr/openwin/lib/libICE.so.6
    0xed880000 /opt/java/j2sdk1.4.1/jre/lib/sparc/libfontmanager.so
    0xfa390000 /usr/openwin/lib/locale/common/xlibi18n.so.2
    0xfa1b0000 /usr/openwin/lib/locale/iso8859-1/xomEuro.so.2
    0xfa190000 /usr/lib//liblayout.so
    0xfa050000 /usr/openwin/lib/locale/common/ximlocal.so.2
    0xfa010000 /usr/u/lal/micview/micview2_1_0_beta1/libBitmapImpl.so
    Local Time = Thu Oct 3 13:32:47 2002
    Elapsed Time = 35
    # The exception above was detected in native code outside the VM
    # Java VM: Java HotSpot(TM) Client VM (1.4.1-beta-b14 mixed mode)
    # An error report file has been saved as hs_err_pid27692.log.
    # Please refer to the file for further information.
    Abort
    From this information I think that the problem should be in the native method setDebug. But I have tried to set a breakpoint at the beginning of that function in the C part but with no luck. The application crashes before it reaches that position in the C file.
    What could possibly go wrong between the setDebug function in the C part and the function call in the Java part?
    When using GDB, GDB cannot figure out what is wrong it just returns a hex address, no function name.
    I would really appreciate some help. I have tried everything that I can come up with!
    Best regards
    Lars

    I have figured out that the application fails on its first call to the native methods.
    So I have this Bitmap class that contains all the native calls and it is defined shortly as follow:
    public class Bitmap {
    static {
    System.loadLibrary("BitmapImpl");
    native void setDebug(int debuglevel, int statistics);
    There are many more native methods defined in Bitmap, but I only show the setDebug method because that is the first one that is executed and also the one that immediately fails.
    My setDebug C function is defined as follow in BitmapImpl.c
    #include <time.h>
    #include <stdio.h>
    #include <limits.h>
    #include <fcntl.h>
    #include <jni.h>
    #include <math.h>
    #include <errno.h>
    #include "Bitmap.h"
    #include "data.h"
    jint debug = 0;
    jint statistics = 1;
    JNIEXPORT void JNICALL Java_Bitmap_setDebug
    (JNIEnv *jenv, jobject jo, jint d, jint s)
    debug = d;
    statistics = s;
    My libBitmapImpl.so file is compiled using the following Makefile and using GNU gcc:
    JAVAPATH=$(JAVAINCLUDEPATH)
    LMACRO=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DSOLARIS
    CSOURCE=BitmapImpl.c
    all:
    gcc -O3 -G $(LMACRO) -I$(JAVAPATH) -I$(JAVAPATH)/solaris \
    $(CSOURCE) -o libBitmapImpl.so
    It is still a total mystory why the application fails. I have tried it on a RedHat Linux machine and there it works fine. But not on Solaris. Only if I use the jdk1.1.8 but not a later one.
    Would really appreiciate some help!
    Best regards
    Lars

Maybe you are looking for