The instruction at "0x106ec144" ...

[CarlaU]

Hi RAMaston,

Have you tried running the executable on a different computer? If so, does it give you the same error message? Also, I know you are not using any custom DLLs but are you using any WinAPI DLLs? If it does work fine on a different computer then it could possibly be that the WinAPI DLLs are corrupt. Also, have you tried running the executable in the LabVIEW environment (the development machine)? Do you have any problems/crashes if you just run the VI and not the .exe? 

Hopefully we can narrow down the problem with a few answers from these questions! Have a good day!

Carla 

[RAMaston]

Thanks Carla, yes the error happens on other computers.  Per appnote I checked and my globals have labels.

DLLs found on target:  Hostname(7/31/01), cviVXDWrapper (6/22/06), LVWUtil32(11/5/98), mxsdd(7/19/07), TgrDD(7/23/07), customresource0009(12/3/07), NISysInf(7/17/07).

No noticable errors on the development machine but it does not run around the clock like the target device.

Another thing that is puzzling is that usually the error will occur sometime within the 1st 24hrs of running, a separate WD client will reboot & resume automatically 1-3 times,  then the system runs without problems for days. ???

[CarlaU]

Hi RAMaston,

Thanks for your reply. So my next questions is are these the DLLs that you are calling? If the VI calls a WinAPI DLL function and uses the full path to the DLL in the Call Library Function Node, the LabVIEW Application Builder will create a copy of the DLL in the data directory of the executable. Some DLLs such as WinAPI DLLs should only reside in one location, such as C:\WINDOWS\system32, otherwise errors/crashes can occur when called. To prevent this, remove the DLL path in the Call Library Function Node when calling WinAPI DLLs. I hope this helps!

Carla

[RAMaston]

I read that appnote too.  All the Hostname, cviVXDWrapper, LVWUtil32 dlls are in c:\windows\system32.  I did find some more recently dated dlls on my development machine and updated the target with these.

[CarlaU]

Hi RAMaston,

Thanks for your reply. Have you tried running the executable on a different computer (not the target computer that you are running it on now)? Also, is there any more information you could give us that could help re-produce the error? Also, have you looked in the data directory of the executable to make sure it did not create a copy of any of the WinAPI dlls? I would suggest that maybe we try changing the path of the dLLs (one at a time) and see if you still get the same error. I'm trying to see if we can narrow down the cause of this error a bit more. Have a great night!

Carla

[RAMaston]

We get similar results on all machines we run this on.  (See msg 5 for hw type).  To date 4 different systems.

Is moving the DLLs to the system folder using explorer sufficient to change the path after reboot?

Here is some more background on what the s/w does.:

The software operates a instrumentation system we manufacture talking to several RS-485 serial instruments, performing calcs, and simple UI to LCD & USB HID.  It is a h/w upgrade of an existing LV6.1 & W98SE based embedded system which has run for over tens years in the field.  Both new and old systems used a compact flash as a harddrive over IDE.  New system is LV8.5 & XP-SP2 and cannot run the old LV6.1 s/w.

Initialization:
Simple local and global variable inits.
Reads machine name from hostname.vi.

Main loop:
Polls data from RS-485 half duplex using VISA ASRL2 COM2. This uses some LV IO inport & outport modules.
Calculates results.
Makes data available over RS-232 com1, TCP/IP server (2ndary loop), and flat file datalog.
Refreshes a WD Client VI running as stand alone .exe via shared variables.  This was added after the initial crashes occured on the new system.

Secondary loops:
TCP/IP server - not active under these conditions.
UI handler.

Taskmanager reports that CPU is 88-98 idle and Memory usage is stable around 130M of 512M RAM usage.

The drawmgr.cpp error only occurs when I use mouse to bring up explorer or move the main application window.

[CarlaU]

Hi RAMaston,

Moving the dLLs to the system folder should be enough to change the path. However, did you also make sure that no other dLLs were created and placed somewhere else on the computer that could be causing the problem?

Also, what we might want to try next is to create a debuggable executable. This would allow you to "connect" to the executable with the LabVIEW development environment and monitor the block diagram of the running executable with highlight execution, probes, and other debugging techniques. Hopefully, using standard debugging techniques, we can figure out where the error is coming from.

[RAMaston]

Looks like it's solved.  I found a huge memory leak as the shared variable library deployment was executing each time through the loop.  Page faults where being created at a rate of about 1M per day!  Other small leaks were found and cleaned up also.