LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application crashes when connecting remotely to debug it

Solved!
Go to solution

Hello again all you helpful forum-goers!

 

I am trying to debug an odd behavior in my application which only happens on a specific computer under specific circumstances.  In order to do so, I enabled debugging in my application, and eventually was able to see it as an option in the "Debug Application or Shared Library" menu item on my local computer (I first had to discover the hard way that you cannot change the name of the application and still have it run in debug mode, even if you change the name of the associated .ini and .aliases files also).

 

When I try to connect to my application, the "Connection status" display lists downloading my many subVIs, and then finally downloading my main VI.  At this point my main VI's front panel appears on my local computer.  However, everything then freezes, while on the remote computer, my application (which had been correctly waiting for the debugger to start) crashes with a generic Windows "...has encountered a problem and needs to close" message.  If I click for more information, I see that the ModName is lvrt.dll (my application is not generally real-time, but it does use a timed loop or two).

 

I would appreciate any suggestions as to what may be causing this error, and how to fix it.  Unfortunately since it is a work application I cannot post my code.  I am using LabVIEW 2010 SP1, and both computers are running Windows XP.

 

Thanks in advance for your time!

 

-Joe

0 Kudos
Message 1 of 7
(2,819 Views)

I also tried running my application and debugging it on my local computer, and it behaved in exactly the same way.  As a further data point, I created a new project with a trivial VI, built it for debugging, and was able to run and debug it on my local computer just fine.  So I would say it is definitely something in the complexity of my large project that is causing it, rather than computer or network settings.

 

I have read in my searches for answers on this problem that various unique features in an application may cause debugging not to work, such as custom run-time menus, or VIs that do not have their block diagrams included.  As to the former, my main VI does not have a menu bar (although a subVI that I call asynchronously under certain conditions later in the program does have a custom menu), so I don't think that would cause a problem.  As to the latter, my impression is that enabling debugging causes all block diagrams to be included, and it is not something where I have to change the source file settings of every individual VI in my project (I sincerely hope not!).

 

Please let me know if any of my assumptions are incorrect, even if you do not have an idea as to what might actually be causing the problem.


Thanks again!

 

-Joe

0 Kudos
Message 2 of 7
(2,793 Views)

I would have also suspected your computer or network settings but as long as you have ensured that they are correct then its time to focus on the VIs. Joe, do you have additional info you could provide?

 

-Danilo V.

0 Kudos
Message 3 of 7
(2,774 Views)

Danilo,

 

Honestly, I'm not sure what part of the VIs could be the problem, given that the application is set to wait for debugger before starting, appears to be doing that, and yet the crash happens before I can start the application.

 

My main VI is a producer/consumer design pattern.  It used to be a more simple state machine, so it has an event handler case which gets called if there is no next state in the queue.  I have relatively recently added an event handler in a separate loop to make it more responsive, but due to budget constraints have only implemented a couple events in the new handler.  I do not think this causes a problem because the two handlers do not share any events.

 

My main VI has two separate VIs it calls in parallel to the main code: a serial port message handler, and a data logger.  Both wait on a global flag indicating the serial port initialization is complete before really doing anything.

 

The main code starts by doing some GUI initialization, then it attempts to open a VI server connection to detect if another of my applications is running on the same computer, reads a registry entry, and then opens 4 copies of a re-entrant serial port monitoring VI, which also wait on the serial port initialization flag.

 

It then goes on to run the meat of the code logic (initializing and querying serial ports, interacting with the user, etc.).

 

Again, I'm not sure how any of that matters given that it is appearing to correctly wait for the debugger before starting.  Any thoughts?

 

The front panel of my main VI isn't anything especially fancy; no sub-panels, no custom menu (no menu bar at all, in fact), no animation, etc.

 

Thanks for your time!

 

-Joe

0 Kudos
Message 4 of 7
(2,772 Views)
Solution
Accepted by topic author jmorris

Okay, I've accidentally worked around the problem, even if I never did discover the root cause.  Smiley Tongue

 

My MS Office applications got upgraded by my IT department yesterday, and now when I go to compile my application, it tells me that a built-in Excel VI is broken, somewhere in the NIReport.llb folder, which I have added to the "always include" section of the source file properties of my application build specification.  I removed NIReport.llb temporarily since I did not need the part of my application which uses it in order to do this debugging, and now debugging my application works.  Weird!  I was able to successfully debug my original problem which started this whole mess, though, so I'm content with the end result.

 

Now I just need to get NIReport.llb working again.  I'm guessing there is probably an updated version to correspond to MS Office 2010, which is my new version.  I had added NIReport.llb in order to support using "Easy Text Report.vi" for printing.  Considering the fact that my application size dropped by 50% when I took it out just now, I may look for another printing option, though.  I may solicit opinions on it, but if so I'll to so in another thread to keep this one focused.

 

To anyone who was reading this thread and thinking about how to fix my problem, thank you for your time!

 

Until next time,

 

-Joe

 

 

0 Kudos
Message 5 of 7
(2,764 Views)

@jmorris wrote:

Okay, I've accidentally worked around the problem, even if I never did discover the root cause.  Smiley Tongue

 

My MS Office applications got upgraded by my IT department yesterday

 

 


It is always more challenging when the problem you are trying to correct is due to changes that you can't control. Im glad to hear that you have found the source of the problem.

 

I'll try to follow along to your next post as well.

 

Danilo V.

0 Kudos
Message 6 of 7
(2,761 Views)

Danilo,

 

Actually, in this case I think the IT upgrade helped.  My application crashing when I tried to debug it pre-dated the MS Office upgrade, so that wasn't the problem.  I think something about dynamically including the NIReport.llb was what was causing the problem.  The fact that it broke in an unrelated fashion and that prompted me to remove it was the only reason I was able to debug my application.  It's a strange series of events.

 

-Joe

0 Kudos
Message 7 of 7
(2,758 Views)