Hello

HonorGamer

HonorGamer

BSOD Kernel Dump Senior Analyst, Web Design
Joined
Jul 22, 2012
Posts
66
Location
Hawaii
Attempting to come back to the world of debugging. Hope everyone is doing well!

Was working on getting everything installed, and the DRT doesn't work on writhziden's tool anymore, does it? Is everyone just using the updated WinDB tool from Microsoft?
 
Hi,

If I'm not mistaken, the DRT used by the app is from Caronna's website. Last I checked, there were only a few pages of Caronna's website still accessible, I do not remember which ones but the DRT isn't one of them.

Alternatively, we have our own DRT started by one of the site founders @jcgriff2
Driver Reference Table
 
axe0, good to see you.

I suppose the app isn't able to be updated because of that. Unsure, but it's okay. The new Windows version isn't too shabby.
 
The developer isn't all that active anymore these days, if the app's going to get an update it may take a while.
 
Yeah I haven't seen writhziden's in years now. I understand. I can use the other tool. I was just curious if there was a current fix for it. Thank you, though!
 
Delka said:
Same issue here... Did you fix it? If yes, how? And using this didnt solve for me:
Driver Reference Table;
Click to expand...
Only the developer who originally wrote the processing tool can resolve it and they're seldom online these days. I wouldn't about it because it only provides a preliminary analysis of the dump files by running !analyze -v over them all. You can do it yourself by using kd.exe I believe and then passing some CLI arguments to it.

Delka said:
Last thing, are you guys using any other program than windb tool from Microsoft?
Click to expand...
Everyone uses WinDbg - it's the only tool which you need.
 
HonorGamer said:
Attempting to come back to the world of debugging. Hope everyone is doing well!

Was working on getting everything installed, and the DRT doesn't work on writhziden's tool anymore, does it? Is everyone just using the updated WinDB tool from Microsoft?
Click to expand...
I'll take a look at this in the next few days. I am curious how many people still benefit from the app vs moving on to other options, or how many benefited from it before being forced to move on due to issues like this. Are there other flags people would like to see supported with different output? Could different output benefit from slimdown options similar to what we did with !analyze -v?
 
Last edited:
It's still quite useful when you have a lot of dump files and you want to get a quick picture of what those are, otherwise I usually just open a few in WinDbg and then use !analyze -v to start with.
 
Thanks @x BlueRobot! I dug into it a bit yesterday, and the problem is pretty deep in the app due to the heavy reliance on carrona.org pages and infrastructure. The Sysnative DRT is missing some key information the app relies on to determine Windows vs 3rd Party drivers, so I need to do some research to see if I can fill in the gaps through other sources or if there is enough information in the DRT to map driver developers. I anticipate 2-4 weeks of refactoring to clean things up and make the app more maintainable while rebuilding the DRT and bluescreen code infrastructure. I'll keep everyone updated as I make progress.
 
@x BlueRobot That's my initial conclusion as well, but I need to go through and see if that assumption holds true throughout. There are also cases where more than one source is listed that includes "Windows Update" for 3rd party drivers, so that's another data point I need to consider in my mapping.

EDIT As a counter point, amdxata.sys has its source listed as Windows Update by itself but is an AMD driver.
 
Last edited:
You could use the following from an elevated PowerShell window:

Code: 
Get-WindowsDriver -Online -All | Where-Object { $_.Inbox -eq $True } | Select-Object Driver

It will provide you with a list of all the .inf files which are associated to inbox drivers. The names will be same as the corresponding .sys files or at least usually are.
 
x BlueRobot said:
It's probably an inbox driver; those which are shipped with the operating system as if they were native drivers.
Click to expand...
That was also my experience, but it still shows that not all drivers map to the source the same way. There are a few outliers in the way John Carrona handled it as well. As an example of those outliers, Microsoft Security Essentials was seen as an app outside Windows even though Windows Update provided its driver updates. Microsoft was the source, but it wasn't considered a Windows driver and was listed as 3rd party. I would say that 99% of the mapping would work as suggested, but I'd need a consensus on the outliers. With Microsoft Defender now built into Windows, I think some of these should probably be updated. What about Microsoft Application Virtualization? Does that now fall under Hyper-V, which is built in as a feature in Windows?

I have some research to do and feedback to consider to figure out the best way to handle some of these drivers in the app.
 
Back
Top