BetaArchive Logo
Navigation Home Screenshots Image Uploader Server Info FTP Servers Wiki Forum RSS Feed Rules Please Donate
UP: 29d, 1h, 8m | CPU: 21% | MEM: 6210MB of 11168MB used
{The community for beta collectors}

Post new topic Reply to topic  [ 9 posts ] 
Author Message
 PostPost subject: How can I understand a BSOD?        Posted: Mon Mar 30, 2009 11:49 pm 
Reply with quote
FTP Access
User avatar
Offline

Joined
Mon Sep 03, 2007 2:47 am

Posts
606

Location
$HOME
Hey!
I would like to know if there is any way to know what a BSOD means, by ex.
I had a problem while updating AVG. When the Antivirus attempted to stop abgldx86 process I got a BSOD. I solved it by my own means, bt I'd like to know if there is a way to "see" the process couldn't be stopped by ex, on the BSOD.
Thank you!

_________________
Image


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Tue Mar 31, 2009 12:11 am 
Reply with quote
Donator
Offline

Joined
Tue Oct 17, 2006 8:26 pm

Posts
932
Lets take the following blue screen example:

Image

So lets break it down...

PAGE_FAULT_IN_NONPAGED_AREA is the exception being thrown. Now, a lot of these errors don't mean a lot to non-kernel programmers, but over time, you learn the causes for certain types of exceptions. In particular, this exception is a memory exception. It can be due to bad memory or a bad sector on disk where memory is trying to swap out to.

0x00000050 is the error code last set by windows before the exception thrown. This CAN give finer detail into the nature of the exception thrown. For instance, this value translates to "The request is not supported". You can look up what a code means by using the following command in cmd.exe:

net helpmsg 50

The four numbers next to the above error code are details about what function was being called when the exception happened. One thing specifically to look at is the first number (0xFD3094C2 in our example). This is the memory address of the function being called. If this is 0x00000000, this ends up being a NULL pointer exception. Typical of bad programming.

The other numbers are a little more inconsequential, but possibly useful. Unfortunately, their meanings are different depending on what failed. The reason for this is, this is the last three values on the stack. In our example, the second number is the IRQ that was being handled.

Hope this helps. However, for a lot of it to be meaningful, you need to have exposure to kernel mode/driver development on windows.


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Tue Mar 31, 2009 2:00 am 
Reply with quote
FTP Access
User avatar
Offline

Joined
Mon Sep 03, 2007 2:47 am

Posts
606

Location
$HOME
:o
Thank you very much!
quite useful.
:)

_________________
Image


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Tue Mar 31, 2009 6:35 am 
Reply with quote
Donator
Offline

Joined
Sat May 24, 2008 10:05 am

Posts
2045
Very useful, sticky worthy even....


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Wed Apr 01, 2009 8:18 am 
Reply with quote
FTP Access
Offline

Joined
Mon Dec 24, 2007 6:07 pm

Posts
63
RentedMule, I don't really analyse this screen like you.

You get
STOP: 0x00000050 (0xFD3094C2, 0x00000001, 0xFBFE7617, 0x00000000)

First, by searching "Bugcheck 0x50" on MSDN website, you get this page.

It is a PAGE_FAULT_IN_NON_PAGED_AREA bugcheck, and that's what is written in plain text on top of screen.
As you see the 0x50 has nothing to do with something that "CAN give finer detail into the nature of the exception thrown", and is in no way linked to "net helpmsg".
For your information, "net helpmsg" translates Win32 error codes, ie those you get in Windows applications. Moreover "net helpmsg" takes decimal numbers and not hexadecimal numbers.

Let's analyse further this bugcheck (by using MSDN web page)
arg1 = 0xFD3094C2 = Memory address referenced
arg2 = 0x00000001 = Write operation
arg3 = 0xFBFE7617 = Address that referenced memory (if known)
arg4 = 0x00000000 = Reserved
Driver leading to the bugcheck is SPCMDCON.SYS.

By using english sentences, we understand that driver SPCMDCON.SYS tried to write to the invalid address 0xFD3094C2.

Once again, arguments 2, 3 and 4 of this particular bugcheck have nothing to do with "the last three values on the stack"(?), nor "the IRQ that was being handled".


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Wed Apr 01, 2009 4:11 pm 
Reply with quote
Donator
Offline

Joined
Tue Oct 17, 2006 8:26 pm

Posts
932
rififi: Wrong. 50 is the GetLastError return value. Not the exception. Likey, the only kernel panic that would have this value is PAGE_FAULT_IN_NON_PAGED_AREA.

The "Memory Address Referenced" is the... wait for it... Memory address of the function currently executing (pretty obvious when the Base Address is included in the crash log). This message would be totally useless to a developer without that, don't you think?

This is an INT1 handler. Hence the second param.

Read Windows NT Internals.


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Wed Apr 01, 2009 8:27 pm 
Reply with quote
FTP Access
Offline

Joined
Mon Dec 24, 2007 6:07 pm

Posts
63
RentedMule, once again, you don't know about what you're talking about.

The bugcheck is raised with KeBugCheckEx function. This function takes one bugcheck code and oh-oh, 4 parameters like what it is displayed on the bugcheck screen.
You're speaking of GetLastError(), which is a user-mode function whereas bugchecks are raised by kernel code. Moreover, not all user mode functions use last error field to return errors, and no kernel-mode function use it, so this value is most of the times meaningless. Finally, that's the GetLastError() of which user-thread (provided you can be in a kernel-mode only thread)?

You get a 0x00000050 in the screen, ie 0x50 (base 16) = 80 (base 10), so why do you give 50 to "net helpmsg", which requires parameter in base 10?

The "Memory Address Referenced" is the... wait for it... address which tries to be referenced, ie the value of the pointer being accessed, and the "Address that referenced memory" is the... wait for it... address of the code which tries to access memory, ie the address of the code which accesses the pointer.
Code may look like that:
Code:
    ...   : int *ptr = (int*)0xFD3094C2;
0xFBFE7617: *ptr = 1;

To finish, i still see nowhere why you're speaking about a "INT1 handler".

I also ask you to read Windows Internals, especially the chapter dealing with Crash Dump Analysis.


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Thu Apr 02, 2009 1:53 am 
Reply with quote
Donator
Offline

Joined
Tue Oct 17, 2006 8:26 pm

Posts
932
I am only dignifying this with a reply so that the poor souls sucked in by your misinformation don't get all mixed up.

Feel free to to join me in #reactos on freenode. I am MindChild. Me and the rest of the dont-know-what-they-are-talking-abouts seem to have a good time recreating an OS we know nothing about. Including my mates who wrote "Windows NT Internals". A bunch of idiots we are.

And while you are on there, why not join #haiku? Where I am maintaining the FAT filesystem driver through voodoo and a lot of guessing...


Top  Profile
 PostPost subject: Re: How can I understand a BSOD?        Posted: Tue Apr 14, 2009 11:45 am 
Reply with quote
Staff
User avatar
Offline

Joined
Sat Aug 19, 2006 8:13 am

Posts
1905

Location
Slovenia, Central Europe.

Favourite OS
Windows 98 SE 4.10.2222B
- RentedMule: No offense, but rififi's points are perfectly valid. While your work is greatly appreciated, you, and your mates, are still human beings, and thus, prone to making mistakes. Which also means, that none of what you, and your mates, write, is to be considered some kind of a Windows Gospel.
And frankly, not only did you give a hex-code as a parameter to a program, which requires a decimal code, but if you look at Microsoft's own knowledge base articles, you'll notice, that each BSOD message is assigned an unique code. In fact, this is how they're raised using KeBugCheckEx (a function mentioned even on MSDN) - by their hex-code. No BSOD fine print, just the numerical equivalent of the BSOD itself.

In fact, let me refer you here, the MSDN page on the KeBugCheckEx routine. Though rififi was wrong about the Memory Address Referenced value's meaning - it IS the address, where the exception occurred, and not the address, which was being referenced by the function, which caused the exception, as rififi stated. But he was still right about the meaning of the hex-code. ;)

_________________
Join #softhistory @ RoL IRC, a nice community for true enthusiasts!
Anime channel: #doki-doki @ RoL IRC, Mibbit, KiwiIRC.
The 86Box help channel is #softhistory now!

Check out our SoftHistory Forum for quality discussion about older software.


Top  Profile  WWW  ICQ  YIM
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 




Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  

All views expressed in these forums are those of the author and do not necessarily represent the views of the BetaArchive site owner.

Powered by phpBB® Forum Software © phpBB Group

Copyright © 2006-2018

 

Sitemap | XML | RSS