12-20-2018 09:51 AM
I'm getting this error in LV2018. Here's the lvlog. Any ideas? Would posting the .DPM help?
12-20-2018 10:57 AM
Did you Google DWarn 0x0E697B77? I did. The first hit is what you want to read.
12-20-2018 02:02 PM
I did. It mentions a .dll. However, there is no .dll mentioned in the crash report - only "ExtFuncRunTime.cpp".
Here is the debug output.
<DEBUG_OUTPUT>
12/20/2018 10:39:40.435 AM
DWarn 0x0E697B77: Caught exception in ExtCode call!
e:\builds\penguin\labview\branches\2018\dev\source\execsupp\ExtFuncRunTime.cpp(92) : DWarn 0x0E697B77: Caught exception in ExtCode call!
minidump id: ca292dd9-7d94-492a-a2f8-c042c245332e
$Id: //labview/branches/2018/dev/source/execsupp/ExtFuncRunTime.cpp#1 $
</DEBUG_OUTPUT>
0x000000013FBE43BC - LabVIEW <unknown> + 0
0x000007FEF0935389 - mgcore_SH_18_0 <unknown> + 0
0x0000000140373C16 - LabVIEW <unknown> + 0
0x0000000142142FB6 - LabVIEW <unknown> + 0
0x000007FEE8A4C050 - VCRUNTIME140 <unknown> + 0
0x000000007709BF7D - ntdll <unknown> + 0
0x000000007707043A - ntdll <unknown> + 0
0x00000000770F86A0 - ntdll <unknown> + 0
0x00000000770B6A4F - ntdll <unknown> + 0
0x000000007709B61E - ntdll <unknown> + 0
0x0000000066D1C8BE - apdm <unknown> + 0
0x0000000000000001 - <unknown> <unknown> + 0
0x0000000200000000 - <unknown> <unknown> + 0
0x0000000037B07740 - <unknown> <unknown> + 0
0x0000000037B0B3C2 - <unknown> <unknown> + 0
0x0000000000000001 - <unknown> <unknown> + 0
0x000000001EB96A18 - <unknown> <unknown> + 0
0x0000000000000002 - <unknown> <unknown> + 0
0x0000000037B07740 - <unknown> <unknown> + 0
0x00000000240F0440 - <unknown> <unknown> + 0
0x0000000140373B6C - LabVIEW <unknown> + 0
0x00000001403759CC - LabVIEW <unknown> + 0
0x0000000037B0A87C - <unknown> <unknown> + 0
12-20-2018 03:50 PM
Something smells kinda fishy there. I wonder if the LabVIEW Runtime crashed? Look at all the unknown values.
When does this happen?
12-20-2018 03:52 PM
Do you call any dlls?
12-28-2018 09:21 AM
Yes, I was accidentally calling a dll. This happened after I switched from using a combo box to a menu ring for selecting "live" vs. "simulation" mode (live mode calls the dll, simulation mode does not). I switched because I was finding myself having to type the two allowable values ("LIVE" and "SIMULATION") into case structures, and decided that I wanted to rule out typos. So I switched to menu rings, so the options would be "0" and "1". Then I mixed up which one was which, and accidentally executed "LIVE" code.
What's the best way to mitigate this issue, i.e. using a menu-style control without either (a) introducing the potential for typos or (b) needing a reminder of which option corresponds to which number? My instincts say to use objects, but I'm not ready to introduce that level of complexity into this program yet.
12-29-2018 07:50 AM - edited 12-29-2018 07:55 AM
You probably first should debug those DLL calls more. Errors like the one you show can and often do happen because of badly configured Call Library Nodes (but a bug in the DLL itself is also not an impossible cause for such errors). Something is overwriting memory that it should not and that corrupts data structures which at some point cause LabVIEW to trip over its feet. This can happen right away after the corruption but often also only happens much later, as the data structures that got corrupted may not be accessed immediately after the execution of your DLL through the Call Library Node.
A very popular Call Library error that many LabVIEW programmers tend to do, is to NOT preallocated buffers to DLLs that the DLL is supposed to write data into. Unlike with LabVIEW VIs and nodes that allocate memory buffers (arrays, strings) anytime they are needed, a DLL can not do that in the same way as there is no managed contract about how to do that. The normal assumptions for most C functions is that the caller always provides any memory buffer that that function is expected to write into. LabVIEW programmers often tend to pass an empty string or array to a DLL function and expect it to automagically adjust that buffer to the size that the function wants in order to write its information into. This automagic however doesn't exist and can't exist. The function simply sees a pointer and has no way to know how large the allocated memory area is for this pointer. So the only thing it can do is to start writing into that buffer and if the buffer is smaller than the function needs to write into, it will write over the end of that buffer and overwrite (corrupt) data it has no business to touch.