LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The instruction at "0x106ec144" ...

Any body seen a message like this.  It is specific to an LV8.5 .exe XP-SP2 application and does not always happen at the same frame(s) or time past launch when running.  Any way to map the instruction, which is always at the same location?  I tried to put debug code in that disable certain parts of the code but I can't relate it to anything.
0 Kudos
Message 1 of 18
(3,773 Views)
Attached is typical screen capture.
0 Kudos
Message 2 of 18
(3,771 Views)
Also getting drawmgr.cpp errors occasionally.  LV8.5
0 Kudos
Message 3 of 18
(3,760 Views)
Don't know about mapping the memory value. Is your application using custom DLLs, or perhaps DAQ-related code?

As for the drawmgr.cpp errors, those are usually graphics-related, sometimes due to the video card or the video card drivers. You can try updating the drivers, or reducing the video hardware acceleration level in Windows.
0 Kudos
Message 4 of 18
(3,745 Views)

No custom .dlls or hw.  Also all front panel controls & indicators are text - no graphics. Vid accelerator is set to full - default.  It crashes more frequently when set to 'None'.  HW is PFM-540I NEW . 

http://www.aaeon.com/PL_Products_List_E062ABE0294D40E1B2_417FE8679547491DBA_TW_utf-8.html

0 Kudos
Message 5 of 18
(3,737 Views)
With any debugger you can see what's located at that location. I guess you
already did that, since you told us you've disabled some code... This kind
of activity falls under reverse engineering, and that is not allowed in big
parts of the world. It is also conflicting with your license agreement, even
if your intentions are good. But that on a side note.

The LabVIEW engineers can find out from the instruction that causes the
crash what is cuasing it. The exeption handling code should give them enough
information about the the part in the source code where the bug is.

Even if you find the location of the bug, and if you can reproduce it, you
will probably never find a way to fix it...

Does it always happen? Do you do anything specific when this happens? Sounds
to me also like a problem with your video card, or how it is configured.

Regards,

Wiebe.


0 Kudos
Message 6 of 18
(3,724 Views)

Thanks Wiebe,

Looks like you're referring to the grapihics issue.  I don't think it is hw since it happens on multiple PFM CPU boards.  I do have the latest OEM video drivers.  It does occur while the LV .exe application is running and I do file browsing on windows explorer of a log file that the app creates.  Also no external I/O LAN, internet, etc...

FYI, not interested in reverse engineering anything.  Just trying to make a reliable product while using Labview.

0 Kudos
Message 7 of 18
(3,713 Views)

Hi RAMaston,

I have been looking into the issue and I think that there are few things that could possibly be wrong. First, are you using any global variables in your code? If you are then these global variables could have gotten corrupted. If the global is formed without a label associated to all the controls and indicators on the front panel data, then the error "memory could not be read" can result. There is a great knowledge-base article that discusses this instance and how to fix it, which can be found here.

Also, this error message occurs when something in the LabVIEW memory space has become corrupted and is often caused by a call to a DLL or CIN code. When LabVIEW is performing garbage collection, it will eventually run into the data corruption and crash. To fix this issue, eliminate any calls to DLLs you might have in your LabVIEW code and see if the crash goes away.

This error can also be caused when running a LabVIEW built executable. 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.To prevent this, remove the DLL path in the Call Library Function Node when calling WinAPI DLLs. There is another great knowledge-base that discusses this error in a bit more detail.

I hope this helps!

National Instruments
Applications Engineer
0 Kudos
Message 8 of 18
(3,696 Views)
Like I said, I know your intentions are good, but it might still not be
legal. Don't worry, I won't tell!

About the problem. Can you make a stripped down version? Perhaps it is a
bug, and happens on all systems.

Regards,

Wiebe.


0 Kudos
Message 9 of 18
(3,685 Views)
I do have a stripped down debug version. That is what I was originally refering too.  Several application functions, such as datalogging, display updating, etc. can be turned off runtime by the use of control booleans. I still could not isolate the problem.
0 Kudos
Message 10 of 18
(3,682 Views)