Crash on screensaver

[8bitbanger]

Hi Folks,

I'm having a really difficult time with my application crashing w/the screensaver. Our IT dept forces a 'blank' or 'XP' screensaver after 10min, and lock on resume. This is not a battle I really want to wage, because in my mind, the crashing is the problem, not the policy.

Windows XP Pro, domain controlled, and this occurs on 7-8 different machines (all machines are only one of two Dell Latitude models).

I can not reproduce it!!!

While in use, the laptops are *off-network* to communicate with compact fieldpoint. Upon resume re-authentication w/the DC is not neccessary, it is cached to a degree.

The front-end application has:

-two bar indicators

-3 strip charts

-3 graphs

-8-9 numerical indicators

-refresh rate of 1second

WHEN it crashes, I get either one of two things -

1) Upon resume, application is simply GONE. No dialog boxes, nothing. Like the app was never running to begin with.

2) An error dialog *similar* in format to the one shown below is displayed (it says something to the effect of "An execution breakpoint has occured").

This has occured about a dozen times now (the machines are in 'production' use) and I just can't seem to catch it.

The application was built in LV 8.5.1 and 2009 - both are problematic. I have updated both PC model's video drivers to no avail (on is Intel, the other nVidia).

Any thoughts? End users are becoming increasingly frustrated, and I'm just out of ideas.

Thank you,

Jamie

[8bitbanger]

OK so I was finally able to reproduce the problem on two separate machines (one of each model thankfully). This is the exact error message displayed (ignore the above post's text).

(Title Bar)<application>.exe - Application Error

The exception breakpoint

A breakpoint has been reached.

(0x80000003) occurred in the application at location 0x0577a7a0

Click OK to terminate the program.

Same error on both machines, different location.

This is of course after the machine has 'locked', after 15min. The screen shows the 'locked' dialog box (prompting you to press CTL-ALT-DEL to unlock it), *with* the above error dialog overlaid.

Of course you unlock and the LV application window is 'ghostly', and closes when you close the error dialog box.

This is the *only* information I was able to find, content wise, related to this error (and this article is NT 4.0): http://support.microsoft.com/kb/230176

"This problem occurs if a program makes a request for memory with the MEM_TOP_DOWN flag set. A bad pointer may be returned, causing the Dr. Watson error message. "

Any thoughts? Could this be related to datasocket reads/writes to the cFieldPoint controller? Never had this problem using the 'FieldPoint Read'/write functions - I moved away from them to avoid the debacle of IAK files.

Regards,

Jamie

[Verne_D]

Hi Jamie,

It looks like there are multiple causes for this error (I've been poking around Microsoft's site and a few other online forums I found on Google), and none are very obvious to the cause. If it is tied to the FieldPoint, you should post in that branch of the forums so you get the right visibility. If it is workable to try both setups side by side, as a test, I might try that.

[RavensFan]

I'd recommend getting a mouse jiggler to prevent the screen saver from coming on.  http://www.cyberguys.com/product-details/?productid=18458

[8bitbanger]

Thanks for the response - I understand this is a difficult thing to track down, especially when you don't have the 'codebase' to help.

I did run a small PSP/Datasocket 'monitor' utility that monitors and can set about 10variables I'm using, with a 20Hz cycle time, and it had no troubles.

I have profiled the memory usage in LabVIEW, but what are the first steps I should take to rule out a memory issue? I don't think this is the cause, because the program can run all day w/out screensaver.

My plan now is to pragmatically 'disabled' portions of the code to try and track it down.

Regarding the jiggler - I have seen this, and considered it, however any attempts to subvert IT policies can result in severe repercussions here, so I don't want to tempt fate.

Any other thoughts are welcome!

Jamie

[ErnieH]

Replace your PC with a RT system. No screensavors. No IT department.

[Verne_D]

It might be in your interest to speak with your IT department about the problem and see if they have any suggestions that would allow you to follow thier policies but maintain functionality. At the very least, they might be able to explain any limitations imposed on the host machine during thier version of locking. Just a thought.

[Rob_Calhoun]

That's an NT kernel debugging message. Check your boot.ini for the /debug switch. Perhaps there is some kind of break point in (the screen saver?!? video driver?!?) that is triggering the debugger, but which would sail harmlessly by if the debugger were not enabled.

You should check your own code for breakpoints, too, although this doesn't really look like LabView-related breakpoint behavior. (Older versions of LabView just crashed if there was a breakpoint in a built EXE, but more recent versions seem to just ignore them.)

[Rob_Calhoun]

Also see if disabling anti-virus software makes it stop (although your IT person will REALLY hate that.)

[8bitbanger]

*Thank you*, I knew there had to be a Windows guru lurking in here somewhere. It's interesting to note that some systems seem to be immune from this problem.

I'll most certainly check the boot ini's.

Disabling the anti-virus is a valid suggestion, though I don't know how it would be associated with a screensaver hook.

Stay tuned.

Jamie