Track back a bad VI from its memory address after crash

[gerh]

Is there any possibility to find a VI based on the stack trace and minidump of a crash report?

Currently I'm chasing after an error in my Labview project which leads to a very sporadic crash - it may happen after a day, a week or a month. I tracked down the problem to a function call to IsDialogControlFromRef which seems to be placed in the labview.exe binary. The function accesses an invalid address which results in a crash of Labview with an access violation error (Exception code c0000005). Also I could exclude any connection to the OS, the PC and hardware connected to the PC, because the crash happens on different machines. One is a PC with a PCI DAQ card and some hardware connected via RS232. The second instance runs in a virtual machine on Windows 10 and all of the hardware is simulated. So, the common factors are Labview 2011 and my code - which grew pretty large over the years.

This is the situation I'm in:

Due to legacy hardware, I can not update to a newer version of LV without major investments. Recent changes in the code made the program crashing occasionally. I could track down the error (see above) using the WinDbg tool. The exact address (0x01030685) where the exception occurs is on both machines the same.

Here is the stack trace (of the development machine):

####
#Date: Di., 15. Apr. 2025 12:55:56
#OSName: Windows 10 Enterprise N 
#OSVers: 6.2
#OSBuild: 9200
#AppName: LabVIEW
#Version: 11.0.1f2 32-bit
#AppKind: FDS
#AppModDate: 07/13/2012 17:36 GMT
#LabVIEW Base Address: 0x00400000



15.04.2025 16:53:38.947
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash: Crash caught by NIER
minidump id: db371d09-38aa-48d6-85bc-5aa525057073
ExceptionCode: 0xC0000005
0x01AB6B29 - LabVIEW  + 0
0x01AB7068 - LabVIEW  + 0
0x71CBDE8A - mscoreei  + 0
0x7C37FDB4 - MSVCR71  + 0
0x77370404 - ntdll  + 0
0x77335626 - ntdll  + 0
0x77349194 - ntdll  + 0
0x77335716 - ntdll  + 0
0x00F875C1 - LabVIEW  + 0
0x01031AAC - LabVIEW  + 0
0x0101C194 - LabVIEW  + 0
0x00DD7C6E - LabVIEW  + 0
0x00CF04E2 - LabVIEW  + 0
0x00D66447 - LabVIEW  + 0
0x00E34E2A - LabVIEW  + 0
0x00E465BF - LabVIEW  + 0
0x00CF04E2 - LabVIEW  + 0
0x00D6915C - LabVIEW  + 0
0x00E2B5D7 - LabVIEW  + 0
0x00B894BB - LabVIEW  + 0
0x014AA768 - LabVIEW  + 0
0x014AD28C - LabVIEW  + 0
0x014AF4F2 - LabVIEW  + 0
0x01B0D6F7 - LabVIEW  + 0
0x01BB79E5 - LabVIEW  + 0
0x01B173E8 - LabVIEW  + 0
0x01B1E348 - LabVIEW  + 0
0x75DC15EB - USER32  + 0
0x75DB7CDA - USER32  + 0
0x75DB78F0 - USER32  + 0
0x75DBBDAF - USER32  + 0
0x773356CD - ntdll  + 0
0x75DB60B0 - USER32  + 0
0x01BB7C6D - LabVIEW  + 0
0x01BB80E7 - LabVIEW  + 0
0x054B14D6 - QtManager452_2011  + 0

Windbg gives this output:

0:000> .ecxr
eax=0019c634 ebx=00000000 ecx=00003a9d edx=000000d7 esi=2244a000 edi=000000c7
eip=01030685 esp=0019c2e8 ebp=0019c6f8 iopl=0         nv up ei ng nz ac pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210297
LabVIEW!IsDialogControlFromRef+0x369c5:
01030685 66394e02        cmp     word ptr [esi+2],cx      ds:002b:2244a002=????

0:000> .exr -1
ExceptionAddress: 01030685 (LabVIEW!IsDialogControlFromRef+0x000369c5)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 2244a002
Attempt to read from address 2244a002

Mass Compile didn't help. The usual reccomendations - cut the whole diagram of a VI and paste it back in, remove code to narrow down the problem etc. - are not feasible, because the crashes happen too random and I don't know which VI of approx. 1k is the bad one. If I exclude the VIs I didn't edit in the latest changes, then there are still approx. 100 left.

How can I track back the executed code to a VI?

[Jacobson]

Without the LabVIEW PDBs I doubt you would be able to do this.

Sometimes, if you look at the entire call stack, you can get a sense of what LabVIEW is doing at that point in time but that's not always very useful if you can only look at the function calls and not the parameters. As an example, you could get a call stack that has some HTTP functions which might only happen in a small part of your application but you could also just see a call stack of LabVIEW doing some low level memory copies which wouldn't point you to anything specific.

[gerh]

Is there any chance to get or generate them? At least for the code inside my VIs? Then I would have a chance to find something next time the program crashes.

[wiebe@CARYA]

---

@gerh wrote:

Is there any chance to get or generate them? At least for the code inside my VIs? Then I would have a chance to find something next time the program crashes.

---

Simple and honest answer is no.

The dumps are mostly useless, esp. to mere users.

Sometimes it helps to get ideas of causes, or to google a bit, but that's pretty much it. Note that you have to assume all the addresses changed over versions, sometimes even over patches.

In your dump, I suspect it has to do with 'some dialog' that might or might not use Qt.

And, IIRC, Qt was added as dependency when the shared variable dialogs where added.

Probably bad info, probably useless even if not. But if it rings a bell it might be a starting point.

BTW The other error log is usually more helpful.

[gerh]

---

wiebe@CARYA wrote:

Simple and honest answer is no.

The dumps are mostly useless, esp. to mere users.

Well, that's unfortunate. Thanks anyway.

---

wiebe@CARYA wrote:

In your dump, I suspect it has to do with 'some dialog' that might or might not use Qt.

A while back, I managed to recreate the GUI of my project in QT 5 Designer with the basic libraries and the QWT library package for all charts and graphs. I didn't even need to change any of the default designs. So, the whole UI just screams "I'm Qt".

Unfortunately, that does not limit the code to any subset, where the bug may be hidden.

---

wiebe@CARYA wrote:

BTW The other error log is usually more helpful.

---

I'm out of luck there as well, because it just points to Labview unknown address in unknown file.

Seems I'm out of options. That sounds a liitle depressing.

But anyways, thanks for all of your help.