BSOD Method and Tips

Vir Gnarus said:
Ahh, that would be the case wouldn't it? Only problem now, is I can't change it back! Any change to the Misc. Options for the post is disregarded.
Click to expand...

It is very strange, isn't it? It doesn't appear to be that after all. For the time being, I have added an underscore before all anchor names to resolve the issue. If I ever figure out a better solution, I will remove those underscores.

Richard
 
Thanks, niemiro, even though it's something I should've bothered with. :)

I'm still puzzled why it's not accepting any changes to the Misc. Options list. Anything I check/uncheck in it is reverted when I save changes.
 
Bump. Added new article and linked to it here under ERROR CODES. It's for 0x19 bugchecks. Planning on adding more command/extension explanations here sometime.
 
Bump. Added some commands, including descriptions I gave in an old post in another forum.

@mgrzeg:

Thanks, mate. I actually have not remembered to watch it yet, but it looks very promising. I'd like to see it first before I add it to the article, so I can give my own personal explanation if it.
 
Bump. Watched those Defrag shows, nice stuff. Added to article. Also updated a couple of things, not much.

I have a feeling this article may be updated more on a per request basis than on personal initiative. I haven't been coming across any scenarios lately in tech support that I've felt is worth writing up on, but at the same time people PM me on some other tech support sites a good number of questions on explanations for stuff. So make a request to have me add to this article about something and I'll do so.
 
Bump. Big mistake on Driver Verifier. Gosh I feel sheepish thinking this way all this time.

I originally thought IRP Logging on Driver Verifier was only available through live kernel debugging because I thought that it could only be done through the DC2WMIParser application to pull the logs. However I have incorrectly interpreted the function of both the application and the IRP Logging setting.

There are two ways to IRP Log for a system. One is - after the client has turned IRP Logging on with Driver Verifier - to start running DC2WMIParser with the appropriate arguments: one to tell what file to dump it to; the other to specify how long to keep it running. Obviously this option is best only when the problematic symptom isn't a crash and it is something that can be reliably triggered, because DC2WMIParser has to be manually initiated. The other option is, of course, to have the system crash. The result is that the WMI information from the IRP logging is still retained, and is accessible through !verifier 0x100. It goes without saying that this information is not retained in minidumps.

I will make the proper correction on the main article now. I reckon everyone who has set up instructions on how to run Driver Verifier should update their stuff accordingly. I apologize for the misconception. IRP Logging is an extremely valuable part of Driver Verifier in many situations, and to say it's inaccessible is to keep people away from such vital diagnostic information.
 
Bump. Added !procdumpext to list of Windbg extensions in Links O' Plenty. This thing is a beast. The !dpx command alone is a great seller. Next time you decide you want to dump the raw stack of a thread, use !dpx instead of dps.

Sorry, niemiro: your extension for dumping raw stacks has served me well for a long time, but it's going to be retired. Thanks for making it, though, it's been a major help to me!
 
Have to agree with Vir, the ProcDump extension is awesome. I've been using it for a few months and it is so handy, especially with user mode dumps. The !deep command is useful too.
 
Vir Gnarus said:
Bump. Added !procdumpext to list of Windbg extensions in Links O' Plenty. This thing is a beast. The !dpx command alone is a great seller. Next time you decide you want to dump the raw stack of a thread, use !dpx instead of dps.

Sorry, niemiro: your extension for dumping raw stacks has served me well for a long time, but it's going to be retired. Thanks for making it, though, it's been a major help to me!
Click to expand...

I don't mind at all! I personally have stopped using loads of my own tools. Times move on, somebody else makes a better alternative, etc. etc. It's really important not to be locked down to one tool, even for me and for something I have written myself. I am just very glad that it helped at all - in actual fact, it's one of my most used programs and it only took about an hour to write. Sometimes I write big programs and they don't get used: but they were not wasted: I've improved my coding skills on them, can probably recycle much of the code, and learned better what's useful and what's not.

I shall have a look at this !dpx command when I get home to see what this magic really is. But it sounds amazing and I really look forward to being able to use it in the future. Thank you for finding it.

Let me say that I'm really happy that I've managed to help at all over the last couple of months. However, let me say also that I have not forgotten how to code these extensions, or lost my empty templates. If you ever think of something which could help you, just give me a shout and I'll see what I can do.

Richard
 
That's where I found out about this thing, myself!

@Niemiro:

There's actually one thing of interest. I've noticed that the purpose of the !dpx command is to consolidate output of dps, dpu, dpa and dpp commands. Yet I did notice in particular in one occasion where I used it once, skimmed through it, then used dpu (dump unicode) afterwards on the same memory range and it actually pulled up items of interest that were not shown in the !dpx output. I know that just about anything can be interpreted as unicode so I would figure the !dpx extension would try to see them as anything else first before considering them as unicode, but I found it odd that it personally didn't find any unicode of value in the memory range, but dpu found two strings of very important items (namely directory strings)! I'm wondering why that was.

The memory dump in question is the last kernel dump linked here, post #33. I switched context to the hung proc (#3), used !thread on it to get limit and base on the thread stack, then used those values to dump with !dpx and dpu and other variants. dpu came up with two directory strings into Chrome and K-Lite Codec directories which !dpx did not pick up.

I'm thinking Andrew placed some filters on what he believes to be "potentially valid" strings which may be filtering out such output.
 
Could I request this blog to be added? Gustavo Duarte

It does a really good job of explaining the internals of an operating system (Windows and Linux).
 
As Vir's IT interests have changed a bit, and since I offered to take care of/add to any thread(s) he has made, I figured I'd finally start off with this one because I quickly noticed a few things that should be added (Carrona/Sysnative DRT were never added to links?!). I am definitely going to be adding a lot of things to the BSOD Information forum from this point on.
 
Last edited:
I see you already went quickly to work on this. Thanks Patrick! Btw, the reason I didn't add the DRT under databases is because I already assumed that if you're on this site, you know about the DRTs! Though for outsiders linking to the article I reckon that won't work so well. Thanks for clearing that up for me!
 
Btw, the reason I didn't add the DRT under databases is because I already assumed that if you're on this site, you know about the DRTs! Though for outsiders linking to the article I reckon that won't work so well.
Click to expand...

I actually assumed that was the case! :grin1:
 
You must log in or register to reply here.
Back
Top