I’m running a progam in debug mode in Visual Studio. After running for several hours, it blue screens my computer, and after about 3 seconds, my computer restarts.
I’ve tried:
Defragging my disk
Running chkdisk
Uninstalling and re-installing Visual Studio
Running the program for a short time, exiting normally, and inspecting the Visual Studio output window for memory leaks or other faults (finding none).
I’ve examined my code and can’t find any problem sufficient to crash the computer. I’m not dynamically allocating memory. The program is a console application, but it does pretty intensive processing. In the program I generate samples 2 different ways, then compare them. I do this 100 million times. The program takes 3 - 4 hours to run.
I’m looking for suggestions on what to try. When the computer restarts, it tells me that there is a mini Dump file, but I don’t know how to read that file. Is there a utility to read it?
How can I get the blue screen to persist, and not automatically restart the computer? Is there any useful information on the blue screen that will tell me where the program was when it crashed the computer?
Is there a way of retrieving a stack trace of where the program was when in crashed the computer? This would give me something to go on. I’ve examined my code and haven’t found anything that is suspect. Besides, a program fault show only crash the PROGRAM, not the computer.
First, Right-click My Computer, select Properties. Select the Advanced tab, and deselect the Automatically Restart option.
This will stop the automatic reboot.
Think about your stack - make sure that it is not overflowing (if you use recursion or nested function calls with local variables you can eat up the whole stack). Check all your boundary conditions - you may be incrementing a pointer out of an array. Check your maths for a divide by zero as you get to the end, or you may hit a numeric overflow.
Add some regular logging to a text file, so you can see if the crash occurs at the same point in the program.
Consider environmental issues - could your processor be overheating under continual load?
Thanks for the notes. I’ve turned off the automatic reboot and left my computer running at home. Hopefully when I get home, it will have crashed and I’ll have a blue screen to examine.
I don’t use recursion. I do use arrays and a pointer problem is a possibility. Divide by zero is unlikely, but marginally possible. All of these things, however, should crash the PROGRAM, not the COMPUTER.
Your last suggestion, though, (overheating) is a possibility. When I run my program, the fan speed is at maximum for hours, so a temperature fault might be the problem. The room I run my laptop in is not unusually warm (about 73F), but I’ve never ran the computer for this long and hard before.
Is there any way I can tell if it IS an overheating shutdown from the blue screen? Or by some other method?
Amusingly enough, the third line of your OP mentions a program that can read .dmp files: visual studio. It isn’t all that likely to be very interesting to you, but it is ppossible to load that dmp in the debugger and see part of the machine state from the time of the crash. Microsoft even provides a public symbols server with debugging symbols for released versions of windows so you can make sense of things like call stacks from your crash. It’s been way too long since I’ve even used VS, let alone loaded a machine crashdump, so I can’t help you beyond that. If the problem is really overheating, though, (and I bet it is) this is unlikely to tell you anything useful.
There are a number of free apps that will monitor CPU temperature (support will vary depending on your laptop). I would consider running one of these and having it log the temp - you can then observe if it’s getting too hot.
I don’t really have any ideas on adding cooling capabilities other than the standard “open desk, don’t block the vent” ideas. You could add some idle time to the program - make it only use 50% of the CPU instead of 100%. That should keep the CPU cool. Of course it will also take twice as long to run…