SysnativeBSODApps - additional check 'drivers found in stack'

No problem on the time taken. I've only encountered that one .dmp so far that caused problems. Thanks for putting it together.

Code:
FAILURE: Dump file is corrupt.
Did you add that message? If so, nice!

Yep, thanks :) I added some simple tests for dump corruption and a failure message if detected (basically, just seeing if the memory addresses can be successfully retrieved, and if they are plausible). I then output the raw data incase an analyst can recover anything useful from it. Here the address to _KTHREAD is corrupt, so the stack base and limits are meaningless, but maybe other times they won't be.

I will upload the source code soon, but there is nothing very interesting or reusable in it. Sadly, nothing magic here :p
 
I uploaded the latest version of the apps, but I'll warn that they are a little slower due to the symbols checking. I am working on a better method for symbols errors to distinguish between when symbols are possibly wrong and when they are definitely wrong. I also want to fix that the apps check symbol errors for each user command even if the symbols could not be fixed in a previous command...

The symbols checking for user commands is still a work in progress, but it should at least be robust now with the new methods. BETA: Sysnative BSOD Processing Apps 2.1.2.7.

I know this is sort of irrelevant now, as your app is working amazingly, but I just came across something which might or might not help you with similar things in the future. It is not exactly what you are after, but I shall post here anyway for the benefit of all: http://www.wintellect.com/cs/blogs/...an-undocumented-windbg-extension-command.aspx
 
I will clean up this thread and split off my extension tomorrow. For tonight, a new version. There have been quite a few changes in this version. Some stuff has moved around, but nothing has been removed. Even if it looks like some functionality has been removed, it has just been moved under a different argument, or whatever.

I would like to thank writhziden in particular for his comments and suggestions on my extension which helped me to make many of the improvements seen in this version.



Firstly, the standard name of the .dll has changed from niemiro to sysnative. However, as ever, this can be changed to anything you so desire. Please feel free to do so.

The main reason for this was twofold. Firstly, this is a team effort, not really "mine". Secondly, my username is hard to spell :lol:



Secondly, rawstack and auto_errrec are quite long to type out if you are using these manually in dump files in WinDBG. So...

I have created a shorter alias for each. rawstack can now be invoked with just rs, and auto_errrec with just ae, e.g. !sysnative.ae or !sysnative.rs -dc



Thirdly, !sysnative.rawstack and !sysnative.rawstack -dps used to be identical. No longer so. -dps remains unchanged, for those of you who prefer the old style output, or want to dig further into a dump, e.g. to look for stack trashing. This functionality will never be removed. But, I don't think that we scrutinise the rawstack for corruption most of the time, so a more concise default output may be appreciated. The full version still exists, but is no longer the default. Please let me know if you object to this change, and I will see what can be done. So, the change...?

  • Now, only lines which map to a valid symbol are displayed. All other formerly blank lines (in the symbol column) are now not displayed.
  • In addition, the first reference to each distinct driver is now shown in bold for attention.

To show you exactly what I mean by this, take a look at some example output below (column alignment is maintained by the extension, lost by the forum):

Read More:


Source code is also included. Some of the commented out code needs a slight tidy up in places, but that should be done for the next version.

As ever, your honest feedback or suggestions on these changes, positive or negative, will be received with gratitude and carefully considered.

I hope you like it,

Richard
 
Last edited:
Version 1.5

Further improved corrupt dump file detection.
It seems one of the updates to the forums erased the attachment here. I have misplaced this version, though I can probably find it if I dig around through all my backups over the years. If you would also need to dig for it, I won't ask you to go through that much trouble, but I thought I'd ask anyway:

@niemiro I don't imagine you still have this somewhere easy to find?

EDIT: I remembered I have a laptop sitting in our basement from the last time I was doing Sysnative troubleshooting work in 2019, and I was able to find this in its file history from an old backup.
 

Attachments

Last edited:

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

Back
Top