LabVIEW 8.0.1 Runtime Crash w/ Application.exe - Urgent!

[Hannamon]

Hello All; here is a strange one for you...

I have LabVIEW 8.0.1 Professional Development System installed on 2 PCs, one running WinXP and one running Win2K.  I have a particular application that I have created (quite large) on my WinXP version, compiled into a .exe. The application runs without incident on my WinXP LabVIEW Deveopment environment, and also under the Runtime.

When I try to run the application on my Win2K machine, the exe crashes immediately after loading (every time).  However, it will run just fine under tdevelopment system on the same PC.  I make no changes from the WinXP to the Win2K machines, and both LabVIEW installations are identical (i.e. LabVIEW 8.0 with 8.0.1 patch installed with mass compile; IMAQ Vision 8.0, and Application Builder).

I have run a thorough Windows Update on both machines.  An older version program (compiled using the same system) will work, but not my latest.  The latest will run fine on WinXP and Win2K Development, but not Win2K runtime.

I am at the point where I may need to start with the older rev code, and add pieces one-by-one until I find the error (assuming it is code related and not some DLL somewhere), but due to program size, that could take days.

Any insight would be much appreciated, as I am under a tight schedule!  Thanks in advance.

DJH

[Kenny_K]

Couple of quick thoughts:  It sounded like you compiled the program oin the XP machine and then tried it on the 2k machine, have you tried creating the .exe using the development environment on the 2k machine and see if it works or not.

Also, not sure if you had an installer or not, but the option to have XP or later my have been checked (although I think that it would have not installed if you didnt have 2k)

Does it provide you with an error when it crashes or does it just fail to load??

Kenny

[amiramke]

Hi,

I don't have a solution for you, but I wanted to share that I had the same problem when I was running a big program on LabVIEW 8.0. Using the development environment everything worked fine, but it crashed with no error message when I ran the executable.

I then opened it using a different computer running LabVIEW 8.0.1 and created a new executable on it. That solved the problem. But since you are using 8.0.1 already, I don't know what to tell you.

Let us know how you solve it!

Ami

[Hannamon]

Thanks for your replies, Folks.

Yes, I have tried compiling on both the Win2K and WinXP machines, with exactly the same results from both.  The program runs fine on WinXP but crashes on Win2K.  The program seems to load, but only gets about 3 or 4 seconds in to the application and then crashes.  It always crashes at the same place and time.

I have tried the runtime installers on several other Win2K machines, making sure the Win2000 checkbox was checked, but still getting the crash.  On my development system, an older program runs fine in the runtime environment, while a newer program is the one that crashes.  So, I know the runtime itself is not corrupted.  I have verified this with several applications.

Things I have tried in the meantime that have not produced favourable results:

- My application uses ActiveX controls (for Excel and HTML report generation... Excel routines are homemade and not the LabVIEW add-on), so, I removed all ActiveX references and routines: program still crashes.

- My application makes use of "add-on tools" which are dynamically loaded during runtime (depending on user selection); all these controls and instances were removed: program still crashes.

- My application makes certain function calls to additional thrid-party DLLs (image framegrabber DLLs for use with mulitple framegrabber cards), all these were removed: program still crashes.

So, what I am left with is an older program that works fine, and a stripped-down newer program that causes crashes.  The differences between the older program and the newer stripped-down program are now almost negligible, so, this is most confusing.

I have also included OK/CANCEL dialogue inclusions to simulate breakpoints when certain VIs are loaded... no effect.  I have tried "pulling" VIs out of the main application.exe and loading them from other directories to see if I can get the crash to follow one of these VIs.  Crash always remains within application.exe.

I have also checked the Dr. Watson log, but this only confirms that there was an issue with application.exe with no real hint as to what specific VI caused the crash.

So, the hunt continues.  Any additional thoughts are welcome, as I am already past deadline.  Thanks!

DJH

[Kenny_K]

I did some more diggin, and over at the LAVA forums, someone said that this is sometimes caused my non-standard fonts when using an application of different platforms.  not sure if you have changed any of the fonts or not.

You might also want to check out this thread which talks about enableing the debugger in an executable (I have not used it ever), and maybe then at least you can find the offensive code.

Ill let you know if I find anything else

Kenny

[Hannamon]

Hello All;

Been doing a LOT of work on this... found some interesting things.

Looks like there may be nothing wrong with any of my code.  As mentioned before, everything has been mass-compiled, dependencies refreshed, all warnings eliminated, etc., etc. with LabVIEW 8.0.1.  Keep in mind, this code works great in Development Mode on both Win2K and WinXP, and works fine in Runtime mode on WinXP.  The problem, as stated before, was when the application.exe is run in the Win2K Runtime environment.

I started with a known working version of code and continually added new code until it was pretty much identical to the current version.  Everything worked great on both Win2K/WinXP.  Then, without any changes to code, in the Application Builder, I set the destination for several VIs to a new directory (i.e. not Application.exe).  I rebuilt the program, and voila, the same program crash as before in Win2K (fine on WinXP).  The funny thing is, that I have several other VIs exported to a separate destination directory, with no issue whatsoever.  Maybe there is a problem with multiple destination directories outside of Application.exe?  All exported VIs were set to "Dynamic".  Going back to the single application.exe and no additional subdirectories is not really an option, due to the size and complexity of the program.

Any thoughts on this?  In the meantime, I am going to upgrade one of my lab PCs to LabVIEW 8.2, and see if I have the same issue, or if this was one of those many bugs in 8.0.1 that were fixed by going to 8.2?

This is a strange one, but any input is MORE than welcome.  Thx.

DJH

[Hannamon]

More information on this issue.  I tried running my program on a PC with JIT Debugger, and got the following information:

 An exception 'Unhandled Win32 Exception' has occurred in DIAAS.exe.

Also, the following script text:

'DIAAS.exe': Loaded 'U:\Software\DIAAS Development\Debug\DIAAS\DIAAS.exe', No symbols loaded.

...

'DIAAS.exe': Loaded 'C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\8.0\nitaglv.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\lkrealt.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\lkbrow.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\NIVisSvc.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\8.0\mesa.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\Program Files\National Instruments\MAX\mxs.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\Program Files\National Instruments\MAX\mxsutils.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\msvcp60.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\NIVision.dll', No symbols loaded.

'DIAAS.exe': Loaded 'C:\Documents and Settings\testontw\Local Settings\Temp\lvs829.tmp', No symbols loaded.

'DIAAS.exe': Loaded 'C:\Documents and Settings\testontw\Local Settings\Temp\lvs82A.tmp', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\WININET.DLL', No symbols loaded.

'DIAAS.exe': Loaded 'C:\WINNT\system32\CRYPT32.DLL', Cannot find or open a required DBG file.

'DIAAS.exe': Loaded 'C:\WINNT\system32\msasn1.dll', Cannot find or open a required DBG file.

Unhandled exception at 0x03b7b71b in DIAAS.exe: 0xC0000005: Access violation reading location 0x00e91000.

Can anyone tell me (please) what is going on with this?  Any assistance would be appreciated.  Thanks!

DJH

[Kenny_K]

I noticed that you have the DIASS.exe (I am assuming that this is the program youcreated) on a U:\ drive.  Is that a network drive or a lcoal drive or USB external, etc?  It may be that 2k has trouble with the network drive or external drive (just guessing here).  If it is a network drive, can you try it on the c drive??  You will have to copy everything over to the c drive and then disconnect the network/external drive (if possible) so that LV does not look for it on the network/external drive.

Did upgrading to 8.2 solve anything??

Can you try running the debugger on the XP machine and compare the results?  I am wondering if you will get all of the "no symbols loaded" on the XP machine too or not.

[Hannamon]

Hi Kenny;

Yes, I have also tried directly from the C:\ drive (U:\ drive is a network drive).  Upgrading to LV8.2 did not, unfortunately, resolve anything.  Although, I did notice that there were quite a few additional AppBuilder settings than with LV8.0.1, which I have not yet explored all of.

No clue as to what the "no symbols loaded" actually means... I will try to find an XP machine with debugger and run the same test.

In the meantime, I'm still stuck.  I did find (in my program) that some TypeDefs had become disconnected, and I also went back to ensure that all my variable representations (i.e. I32, DBL, SGL, etc.) were being converted properly.  I found a lot of instances where this may not have been the case, and have corrected those.  We'll see if it makes a difference.

Keep those thoughts coming!  Thx.

DJH

[Kenny_K]

I am sure that you have tried it already, but the type definition diconnection could be because the "Disconnect type definition sand unused polymorphic vis" was checked under the advanced settings when you build the application.

Kenny