BSoD when shutting down.

[Kheldar]

So here's the story. I've got an acer aspire running windows xp sp3. A couple days ago it started to do this weird thing where it would get a blue screen of death right before it was completely turned off. (this only happened when I *chose* to shut down).

Earlier today this problem got worse. Whenever I turn on my computer, instead of booting windows normally, I get sent to the "your computer did not shut down properly" page. This isn't a major concern, but whenever I choose to boot normally, the same kind of thing that was happening only when I was shutting down, happened whenever the windows loading screen ended. (at startup).

The annoying thing about this whole thing is that the blue screen is only there for a tenth of a second, the computer loses all power shortly after. This means I haven't been able to see whatever error message I've been getting, which means I haven't been able to properly search for a solution.

I'm now booted into safe mode. If anyone can recommend a way to find out why this is happening, or what kind of error messages I'm getting, I'd appreciate it.

[Cool_Fire]

What kind of BSOD? IRQ fail? Hardware error?

[Kheldar]

What kind of BSOD? IRQ fail? Hardware error?

I haven't been able to see the message on the blue screen, as it vanishes when the computer loses power, which is close to a tenth of a second later.

Anyways, I've been doing some digging around and I found a broken driver via Computer Management->Device Manager

Spoiler: show

I tried the "search for updates" button, but windows insists it's the best fit for my computer.

I just came across this http://msdn.microsoft.com/en-us/library/aa938711.aspx, thanks to google, so I'll read that and decide whether or not removing it's the next step.

[SLaX]

I hate blue screens. They usually are caused by bad drivers trying to access a memory block that's being used. Here's a nice tutorial on how to debug these little buggers. Hopefully you can narrow it down.

Debugging Kernel Mode Blue Screens
All Articles > Computer Repair
Article ID: 16
Published To: Internal Users Only
Status: Active

Debugging Kernel Mode Blue Screens



All blue screen crash minidumps are stored in C:\WINDOWS\Minidump directory. For full dumps, find the Memory.dmp file in the C:\Windows\ directory.

First you must install the debugger and the symbols. You CAN debug a 64 bit memory dump on a 32 bit system, and vice versa.


For 32 bit Debugging:

http://www.microsoft.com/whdc/devtools/ ... x86.mspx#a


For 64 bit Debugging:

http://www.microsoft.com/whdc/devtools/ ... 64bit.mspx



Install the debugger and run it (WinDbg).

In the GUI, open the memory.dmp file you want to analyze.

You will then get an error saying something about symbols. To find symbols, go to the bottom and run the command:



!symfix



Most commands start with a !

This command will connect the debugger to Microsoft's public symbols library on the Internet.

Next, you must save your workspace with



File>Save Workspace.


Then close WinDbg and reopen it. Then reopen your workspace file, then reopen your memory dump.

Now you should not receive the symbols errors.

You should see some kind of Stop Code being debugged. Something like



Stop 0x000000D1



To view more information on the stop error its self you can open the File>Help menu, click on



Debugging Techniques>Bug Checks (Blue Screens)>Bug Check Code Reference



to view stop errors and their meanings.

You may now get a clue as to what is causing the problem. The debugger may show:



Probably caused by :



This will identify what file caused the blue screen. Most all blue screens are caused by a bad driver. If you want to analyze further, which you should, run the command:



!analyze -v



Under the parameter Module_Name:



you may see a driver name that will be a blue link. This is the problem driver. Click it and you should get more details on the driver its self.



In the stack text, you may also get some clues as to what caused the blue screen.





Terminology:

Blue screen
When the system encounters a hardware problem, data inconsistency, or similar error, it may display a blue screen containing information that can be used to determine the cause of the error. This information includes the STOP code and whether a crash dump file was created. It may also include a list of loaded drivers and a stack trace.



Crash dump file
You can configure the system to write information to a crash dump file on your hard disk whenever a STOP code is generated. The file (memory.dmp) contains information the debugger can use to analyze the error. This file can be as big as the physical memory contained in the computer. By default, it's located in the Windows folder, and you CAN call them "memory dumps" without fear of offending anyone.

Debugger
A program designed to help detect, locate, and correct errors in another program. It allows the user to step through the execution of the process and its threads, monitoring memory, variables, and other elements of process and thread context.



Kernel mode
The processor mode in which system services and device drivers run. All interfaces and CPU instructions are available, and all memory is accessible.



Minidump file
A minidump is a smaller version of a complete, or kernel memory dump. Usually Microsoft will want a kernel memory dump. But the debugger will analyze a mini-dump and quite possibly give information needed to resolve. If it's all you have, then debug it, rather than waiting for the machine to crash again. Open the file in the debugger (see below) just as opening memory.dmp in the demonstration.



STOP code
The error code that identifies the error that stopped the system kernel from continuing to run. It is the first set of hexadecimal values displayed on the blue screen. At a minimum, frontline Admins should be required to note this code, and the four other codes displayed in parenthesis, and any drivers identified on the screen. Often, this is all you really need!



Symbol files
All system applications, drivers, and DLLs are built such that their debugging information resides in separate files known as symbol files. Therefore, the system is smaller and faster, yet it can still be debugged if the symbol files are available. You don't need the Symbol files to debug - the debugger will automatically access the ones it needs from Microsoft's public site.

[ramiia]

I could say that we are on the same boat @threadstarte,

@slax can I install that debugger using ubuntu livecd? as I cannot boot on windows properly... win logo>bsod>restart>loop

[Cool_Fire]

can I install that debugger using ubuntu livecd?

I'd have to say probably not.
Something about installing kernel hooks on the running kernel, registry entries and probably lots of other stuff.

Does it also BSOD in safe mode? If not you could try installing it there.