[SOLVED] Hyper-link bugchecks in output summary info

usasma

Retired Admin
Joined
Feb 20, 2012
Posts
2,126
This one might appear a bit self-serving, but it came to me because I can't remember what all the BugChecks are or what are the primary problems that they are caused by. Amazingly (at work) people acutally expect me to know what I'm doing with this BSOD stuff! :0) :

1) Insert the Symbolic Name into the output options. This is the "MEMORY_MANAGEMENT (1a)" like line just under the *****'s in the 99 file (colored RED in the quote box below):
1: kd> kd: Reading initial command '!analyze -v; !sysinfo cpuspeed; !sysinfo SMBIOS; lmtsmn; q'
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000005005, The subtype of the bugcheck.
Arg2: fffff70001080000
Arg3: 0000000000000866
Arg4: 000000000000079c

2) Include a hyperlink to that particular BSOD entry at http://www.carrona.org/bsodindx.html for each instance of the BugCheck code in the 98 and Template output (although it would be nice to have it in the 99 and 97 also). This would make it easier for an analyst to check the page for Usual Causes, KB articles, more detailed explanations of the bugchecks, and any undocumented references.
Syntax is:
Code:
http://www.carrona.org/bsodindx.html#0x0000001A
 
Re: and yet another suggestion

I'm sure you can imagine that this will take quite a bit of time to implement given the vast range of codes.

John Griffith often jokes that the next step in the apps will be to link them to all forums and let them analyze the apps and respond to the users, eliminating any need for us analysts. I think this request is moving in that direction. :lol:
 
Re: and yet another suggestion

One or two questions before I start on this tonight: Where would you like the output? Do you want it below the code box of the analysis, or would the information be okay to include within the analysis code box?
 
Re: and yet another suggestion

First off, there's no rush for this. We've been doing quite well without it for a long time.
Next, you've got a new job - that comes before this. You've gotta establish yourself as a dependable employee.
 
Re: and yet another suggestion

SYMBOLIC NAME output - I'd like to see it in the Template and the 98, with the 97 also if it's not much additional work
It should be positioned somewhere near the BugCheck string(s) so that it's obvious that it belongs with that bugcheck.

Links - I'd like to see it in the Template and the 98, with the 99 and the 97 also if it doesn't require a lot of additional work.
There's several instances of the bugcheck number in the output - so you'd have to make at least one required so that the link will be associated with it
I'd include them in ( )'s right after the BugCheck string (or write the link so that the BugCheck string is clickable for the link at carrona.org).
 
Re: and yet another suggestion

Thanks for understanding. I will try to get this done over the next month and have it in the next release, but it may end up being two or three months. I can provide you with a better timeframe once I've started and see how many codes I can do per day within my half hour a day period I have set aside for working on the apps / answering new blue screen threads.
 
Re: and yet another suggestion

SYMBOLIC NAME output - I'd like to see it in the Template and the 98, with the 97 also if it's not much additional work
It should be positioned somewhere near the BugCheck string(s) so that it's obvious that it belongs with that bugcheck.

Links - I'd like to see it in the Template and the 98, with the 99 and the 97 also if it doesn't require a lot of additional work.
There's several instances of the bugcheck number in the output - so you'd have to make at least one required so that the link will be associated with it
I'd include them in ( )'s right after the BugCheck string (or write the link so that the BugCheck string is clickable for the link at carrona.org).

The symbolic name output is already an option for the template and importantInfo.txt file. I had not added it to the 98 or 88 since those were based on the older version of the app, but I can add it with a couple simple lines of code.

There are a couple ways we could do this. Something like:

Code:
[font=lucida console]**************************Thu Aug 16 07:05:26.781 2012 (UTC - 7:00)**************************
Loading Dump File [F:\BSODDmpFiles\ahmedyar91\Windows7_Vista_jcgriff2\081612-36800-01.dmp]
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Built by: [B]7601[/B].17835.amd64fre.win7sp1_gdr.120503-2030
System Uptime:[B]5 days 1:35:26.667[/B]
BugCheck Code: [B]BugCheck 3B, {c0000005, fffff800032d8474, fffff88007aece50, 0}[/B]
Probably caused by :[B]ntkrnlmp.exe ( nt!IofCallDriver+44 )[/B]
BugCheck Info: [url=http://www.carrona.org/bsodindx.html#0x0000003B]SYSTEM_SERVICE_EXCEPTION (3b)[/url]
BugCheck Usual Causes: System service, Device driver, graphics driver, ?memory
Arguments: 
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff800032d8474, Address of the instruction which caused the bugcheck
Arg3: fffff88007aece50, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x3B
PROCESS_NAME: [B]svchost.exe[/B]
FAILURE_BUCKET_ID: [B]X64_0x3B_nt!IofCallDriver+44[/B]
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
**************************Thu Aug 16 09:12:43.173 2012 (UTC - 7:00)**************************
Loading Dump File [F:\BSODDmpFiles\ahmedyar91\Windows7_Vista_jcgriff2\081612-36922-01.dmp]
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Built by: [B]7601[/B].17835.amd64fre.win7sp1_gdr.120503-2030
System Uptime:[B]5 days 1:25:26.667[/B]
BugCheck Code: [B]BugCheck 3B, {c0000005, fffff800032d8474, fffff88007aece50, 0}[/B]
Probably caused by :[B]ntkrnlmp.exe ( nt!IofCallDriver+44 )[/B]
BugCheck Info: [url=http://www.carrona.org/bsodindx.html#0x0000003B]SYSTEM_SERVICE_EXCEPTION (3b)[/url]
BugCheck Usual Causes: System service, Device driver, graphics driver, ?memory
Arguments: 
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff800032d8474, Address of the instruction which caused the bugcheck
Arg3: fffff88007aece50, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x3B
PROCESS_NAME: [B]svchost.exe[/B]
FAILURE_BUCKET_ID: [B]X64_0x3B_nt!IofCallDriver+44[/B]

Or after the code:

BugCheck Info: SYSTEM_SERVICE_EXCEPTION (3b)
BugCheck Usual Causes: System service, Device driver, graphics driver, ?memory
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
BugCheck Info: SYSTEM_SERVICE_EXCEPTION (3b)
BugCheck Usual Causes: System service, Device driver, graphics driver, ?memory
 
Re: and yet another suggestion

Don't worry about it - and don't worry about a timeframe!
It gets finished when you get around to it.
The apps are great the way that they are and we're all happy to have them!
 
Re: and yet another suggestion

How about this?:
Code:
BugCheck Code: BugCheck 3B, {c0000005, fffff800032d8474, fffff88007aece50, 0}
BugCheck Info: [URL="http://www.carrona.org/bsodindx.html#0x0000003B"]SYSTEM_SERVICE_EXCEPTION (3b)[/URL]
BugCheck Usual Causes: System service, Device driver, graphics driver, ?memory
Probably caused by :ntkrnlmp.exe ( nt!IofCallDriver+44 )
Usual causes is handy, but it's more than likely to be blank most of the time.
I can make an effort to populate the blank one's with "Device Driver" if it'll help.
 
Re: and yet another suggestion

How about this?:
Code:
BugCheck Code: BugCheck 3B, {c0000005, fffff800032d8474, fffff88007aece50, 0}
BugCheck Info: [URL="http://www.carrona.org/bsodindx.html#0x0000003B"]SYSTEM_SERVICE_EXCEPTION (3b)[/URL]
BugCheck Usual Causes: System service, Device driver, graphics driver, ?memory
Probably caused by :ntkrnlmp.exe ( nt!IofCallDriver+44 )
Usual causes is handy, but it's more than likely to be blank most of the time.
I can make an effort to populate the blank one's with "Device Driver" if it'll help.

I will need to change the order a bit for that to work, but it should be doable.

Also, no need to update the Usual Causes on the site. Any empty ones, I can add the info into the apps based on my own experiences and MSDN articles. The 0x133 issue in Windows 8 is one I can think of offhand; Drivers and/or hardware conflicts/faults, display card, display card drivers all seem to be the usual causes so far that I am aware of. I can also ask you in here if I need help. :-}
 
Re: and yet another suggestion

Then where does the app get the Usual Causes info from?
Wouldn't it be best to have it all in one place?
If you update the html file, I'll gladly upload it when you finish with it.

FYI - I'm headed out the door right now and may not respond for a while.
 
Re: and yet another suggestion

Then where does the app get the Usual Causes info from?
Wouldn't it be best to have it all in one place?
If you update the html file, I'll gladly upload it when you finish with it.

FYI - I'm headed out the door right now and may not respond for a while.

Also was headed out the door to head to work. It would be good to have it in one place, but the html file would be a bit of a pain to parse due to having to also parse out the html code and reformat some of it. I think it would be easier to copy and paste it into a .txt file or .rtf file, parse that into an array of strings, and add info to that .txt file or .rtf file based on what we find as we go. If you have any suggestions, please feel free to share.

For instance, what are your experiences with the 0x133 crashes? Any culprits that I missed?
 
Re: and yet another suggestion

I got most of my "Usual Causes" stuff either from research on the web, or from the contents of the WinDbg help file.
As for STOP 0x133 - those that I've seen are mostly video, but they can be either hardware or drivers.

I'd suggest leaving the Usual Causes out then - as they don't always lend themselves to reliable interpretation, they could be distracting if included in the 99/98/97/Template output, and maintenance of a duplicate resource could confuse things if they aren't kept sync'd up on a continuous basis.
 
Re: and yet another suggestion

@ Mike - assuming for the moment that "Usual Causes" will be left out -- is it possible to give the user the capability to input a URL somewhere (similar to what we now have for DRT URL) and then have the app use that URL + a "hard-coded" tag that the app would assemble (for lack of a better term)?

...\dmpOptions\driverInOut.txt on my system contains:
Code:
[COLOR="#000000"] [PLAIN]https://www.sysnative.com/drivers/driver.php?id=
http[i]:[/i]//www.sysnative.com/drivers/driver.php?id=<driver Name>[/PLAIN][/COLOR]

Example:
- x1 = %userprofile%\SysnativeBSODApps\
- x2 = dmpOptions\bugcheckURL.txt

Where the contents of %x1%%x2% would be something like:
Code:
[COLOR="#000000"] [PLAIN][url=http://www.carrona.org/bsodindx.html#<bugcheck>]
http[I]:[/I]//www.carrona.org/bsodindx.html#[color=#cc00ff]<bugcheck>[/color][/url]
[/PLAIN][/COLOR]

- the app would perform a one-time read of %x1%%x2%
- SET x3 = contents of file %x1%%x2%
- SET <bugcheck> = bugcheck only, i.e., parms 1-4 NOT included
- when the BugCheck Info: line is encountered while writing 98, 97, other (??), substitute %x3%<bugcheck>

The hyper-linked output (with <bugcheck> to be populated by the app) =
Code:
[url=http://www.carrona.org/bsodindx.html#<bugcheck>]
http[I]:[/I]//www.carrona.org/bsodindx.html#[color=#cc00ff]<bugcheck>[/color][/url]

The one area that I have not given thought to is where to obtain the bugcheck info, i.e.,
Code:
BugCheck Info: [COLOR="#FF0000"]SYSTEM_SERVICE_EXCEPTION[/COLOR] (3b)

We could create a SQL file at carrona.org containing 2 fields -
  1. Bugcheck
  2. Bugcheck Description
Such a table could easily be maintained at carrona.org via PHP screens or direct SQL DB editing and write a text file to - http://www.carrona.org/drivers/files

I estimate such a text file to be <10k in size.

It is possible for PHP to strip off/ carve out the info needed (bugcheck, bugcheck desc) from a carrona.org HTML page, update a SQL file or simply bypass SQL and write directly to a text file. I think downloading then parsing a 1 MB+ HTML page at the local level (by the app during runtime) would significantly increase the app's run-time and would therefore be counter-productive.

Info on bugchecks; bugcheck descriptions - https://www.sysnative.com/forums/showthread.php/3285-Bugchecks-CHM

I am fairly certain that the attachment to that post came from carrona.org; however, I am unable to find the page ATM. I'm attaching a copy of the attachment to this post.

Personally, I don't like the idea of including "Usual Causes" in the dump output summary as (1) the info is one click away; (2) it may lead to confusion by the OP (seeing something different than what the BSOD Analyst is having the OP focus on; (3) if given the option, I myself would not use it


Please know, Mike, that the above are simply my suggestions and initial thoughts. You obviously know your code better than anyone. :dsmile:

Also, this is my 1st attempt at comment after reading this entire thread after a long day in Philadelphia, so apologies in advance if there are typos or other mistakes in logical flow.
 

Attachments

Last edited:
The most difficult part of all this is that BugCheck Code is empty probably 15-20% of the time, so that line does not even show up in the analysis output. BugCheck Info is always available, but you'll note that the letters inside the parentheses are always lower case, whereas the BugCheck Code is always upper case. Also, the parenthetical information can be 8e or it can be 100000008e to further confuse things. That makes it difficult to parse things out of the html as you had suggested unless converting all to lower case and then adding the 0x... info based on the string length within the parentheses.

The string for the BugCheck Info, i.e. SYSTEM_SERVICE_EXCEPTION, is really the only way to find information within the html file. The link to the carrona.org would have to be parsed out based on what comes after STOP in that string. I do not think there is any reason to have user input on the link setup for this since it will depend on what the BugCheck actually is within the analysis; it makes more sense to have it hard coded and then wrap the BugCheck Info output within url tags based on what the BugCheck Info string is minus the parenthetical information with the lower case letters, or to do a conversion to all lower case or all upper case of the BugCheck Info parenthetical information and search that way.
 
Alright, I am able to parse out the bugcheck code, the usual causes, and the links.

The usual causes that are empty read: " Still Investigating..."

As you update the usual causes, the apps will download the html file and update accordingly.


The apps should be ready for release after a few days of testing.
 
Can you just leave out the Usual Causes?
It'll clutter up the output, users/analysts may focus on it rather than on the error itself, and there's an awful lot of empty spaces there.
It's not all that significant to an analysis - and as an analyst becomes more experienced there's not much use in even looking it up.
 
John, as with any addition to the analysis output, I can give an option to turn it on or off. I will make the default behavior off at your request. Another option is to have it output to a different .txt file that can also be an optional output file so it does not clutter up the 98, 88, template, and importantInfo outputs.

I am somewhat confused since your original suggestion seemed to focus mostly on the need for the usual causes output so you can use it at work. Is the link enough for you to be able to use at work to get to that information?
 
I didn't intend to suggest that the info should be included in the output - rather I wanted to suggest that the inclusion of a link would make it easier to access that (and other) information present in my BSOD Index web page.

IMO, if more and more info becomes included in the app, then the tool will become unwieldy and more difficult to use.
 
Okay, thanks for the clarification. I will just add the link, then. We can always add the other information at a later date if you do end up deciding you want it or if others ask for it. I imagine the link will suffice, though. :-}
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top