Labview stops with dAbort

[notany]

Hi,

After a few hours of operation, our application terminates with an error. 2 x LVLog.txt attached. Can anyone give me a hint where the problem could be.

[JÞB]

I am going to guess that your app has some overlapped FP Objects that resize and redraw.  Run the source code through VI Annalyzer to find the questionable objects and stop allowing pane resize events.

[notany]

Hi,
thanks for the hint, but I don't think that's the problem as there is only one big ActiveX on the front panel. There are many other Vis with much more front panel objects, but they are not visible.

[notany]

Anybody an idea what the failure code 0xAAA99592 means?

[wiebe@CARYA]

---

@notany wrote:

Anybody an idea what the failure code 0xAAA99592 means?

---

It means somethings wrong 😉.

Have you looked at the memory consumption while running? If it goes up, you have a memory leak.

Even if you don't see a memory increment, there could be a reference leak. A reference is only 8 bytes, but if you have a few 100k of them (<1MB), it's still a good way to crash your application.

Working with references (.NET or .COM) isn't always done as it should. But without seeing any code, it's hard to tell.

I'm not too convinced that DAbort 0xAAA99592 is an error code, it could be a memory address of the exception. This means every compile of LVManager (managing resources like references?) will have this code at different (relative to base) memory location. So, the reports will be spread thin...

For now, I put my money on the ActiveX code.

Can you slow down or disable the ActiveX code? Or speed it up? See if 10Xspeed crashes 10X faster? Once you for sure what causes the problem, you can pin point the problem by repeating this test: try to isolate code or make parts execute 10X (100X, 1000X) more often. Until you find the cause.

[notany]

Hi,

no, I can't change the speed. 

Memory consumption is fine. Sometimes it takes a week (cycle time ~10 seconds) to get the error.

And yes, the 0xAAA99592 could be a relativ address, too. 

In the meantime we were in contact with NI support, but the help was a link to this page (I guess he searched for the error code in the web).

It's a bit sad and disappointing that NI isn't willing to provide a bit more support so that we at least know what to look for.

[notany]

I got another lvlog.txt

[notany]

I have some more information right now:

0AAA99592h is a error code thrown by labview if gdi32:DeleteObject fails 

This part of the lvrt.dll (DDestroyRgn) tests if the handle is zero, if not it calls gdi32:DeleteObject. If this fails it throws the error 0AAA99592h 

DDestroyRgn: 0000000071EB90E0 sub rsp,88h
0000000071EB90E7 test rcx,rcx
0000000071EB90EA jne 0000000071EB914B
0000000071EB90EC lea r9,[726F1600h]
0000000071EB90F3 mov qword ptr [rsp+80h],rbx
0000000071EB90FB mov r8d,1091h
0000000071EB9101 mov dword ptr [rsp+20h],2
0000000071EB9109 lea rdx,[726F15B0h]
0000000071EB9110 lea rcx,[rsp+30h]
0000000071EB9115 call 0000000071DFC6E0
0000000071EB911A lea rdx,[7224D398h]
0000000071EB9121 mov rcx,rax
0000000071EB9124 mov rbx,rax
0000000071EB9127 mov dword ptr [rax+1Ch],0F11816BCh
0000000071EB912E call 0000000071DFC830
0000000071EB9133 mov rcx,rbx
0000000071EB9136 call 0000000071DFCFC0
0000000071EB913B mov rbx,qword ptr [rsp+80h]
0000000071EB9143 add rsp,88h
0000000071EB914A ret
0000000071EB914B call qword ptr [7219D1C8h]
0000000071EB9151 test eax,eax
0000000071EB9153 jne 0000000071EB918A
0000000071EB9155 lea r9,[726F1600h]
0000000071EB915C mov dword ptr [rsp+20h],4
0000000071EB9164 mov r8d,10A4h
0000000071EB916A lea rdx,[726F15B0h]
0000000071EB9171 lea rcx,[rsp+30h]
0000000071EB9176 call 0000000071DFC6E0
0000000071EB917B mov rcx,rax
0000000071EB917E mov dword ptr [rax+1Ch],0AAA99592h
0000000071EB9185 call 0000000071DFCFC0
0000000071EB918A add rsp,88h
0000000071EB9191 ret

[notany]

In some cases DDestroyRgn is not called with a valid handle, but with a long ptr (pointing somewhere in win32u.dll)

[notany]

A few steps before the call of DDestroyRGN the Handle is valid

The function before DDestroyRGN changes it