01-23-2020 11:48 AM
Have you tried the NI Desktop Execution Trace tool?
01-23-2020 12:09 PM
In my experience, turning on logging and/or debug mode in any application makes it run "differently" (e.g., "slowly" because of all the extra code involved with logging injected into the app), and in some cases, poorly. Ironically, debug mode can even crash the application that it was invoked in to help figure out why an app is crashing. IMO, debug mode shouldn't be on in released software.
That being said, if LabVIEW was okay with ignoring, it, it's probably okay for you to ignore it, also. I would be more concerned if it said something like, "Warning: Could not [insert verb here] the window (0x059864a8)." (This a purely made up log entry.)
01-24-2020 02:19 AM
@Artem.SPb wrote:
wiebe@CARYA wrote:
Have you looked in the windows manager (ctrl+shift+w, IIRC, w\ debugkeys on)? You might (be very, very lucky and) find the referred window in the list. If you get a change to do that before the crash.
I tried to find a window on the specified handlers by three programs (Microsoft.Spy, NI WIN monitor), but this is not in the lists.
I found one problem - an exception in an external dll
But the problem with freezing is elusive.
I had my share of freezing.
Is there anything specific you do that triggers it? In my situations, it callback events combined with cloned VIs in (recursive) subpanels where a good way to reproduce freezing. But only on specific user actions (triggering those callback events while removing the clones form their subpanel)...
It will be hard to advice without any inside knowledge about the program.