BlueScreenView Vs Debug Tools for Windows

mikeyjames · 07 Jun 2014

Hi all,

I have pretty basic knowledge of this stuff. A while ago I was getting a lot of crashes and was relying on Windows Debug Tools. Everything always pointed to nvlddmkm.sys and the video TDR thing. After cancelling all overclocks, checking disks etc etc, I eventually replaced the video cards in January (along with a full system strip down and clean). Everything was fine. All of a sudden it's 'here we go again' from last Sunday.

As usual all of the crash dumps viewed in Debug Tools give the usual "Probably caused by : nvlddmkm.sys" and further analysis reveals "VIDEO_TDR_FAILURE (116)"

Crashing about twice per day - can be something as simple as working on a basic document when it happens. Every analysis points to the same thing.

I have just discovered BlueScreenView today and looked at the same dumps. Low and behold I get a variety of different causes listed here, such as :

dkgkrnl.sys - DirextX Graphics Kernel
TeeDriver64.sys - Intel Management Engine
Discache.sys - System Indexer Driver
nvlddmkm.sys - Nvidia WKM Driver
dxgmms1.sys DirectX Graphics MMS
adf.sys - Adobe Drive File System
Null.sys - NULL driver
Ntfs.sys - NT File System

I can see there is still a lot of stuff related to video, but equally related to what I would assume is disk related stuff.

Why is there such a discrepancy between BlueScreenView and the Debug Tools?

Am I seeing video and disk related stuff all of the time simply because there is always video and disk related activity and there is nearly always going to something loaded related to these two things when a crash happens?

I'm not asking someone to analyse this for me just some general clues.

Appreciate any help

Cheers
Mick

Thedoctor44 · 07 Jun 2014

Well Windows Debugging Tools, specifically Windbg allows you to analyze everything in that crash dump.
So if something isn't clear on the cause you can use Windbg to find clues if you like.

WhoCrashed or BlueScreenView only gives you the bugcheck, the parameters and the probably caused by which can actually be a false positive, for example when you get 0xA bugchecks a lot of the time you get the

Code:

Probably caused by : Ntoskrnl.exe

99% of the time this is wrong unless the OS has been corrupted badly.
The main reason this gets the blame is Windows cannot find the driver responsible at all and because the crash happened in Kernel Mode it points it to the Kernel module.

Some times you might have to go into a lot of detail to find the cause which BlueScreenView can't do, an example of this is 0x101 bugchecks which require Kernel Memory Dumps to properly analyse, I used to use BlueScreenView a very long time ago so I can't remember if you can look at KMDs in it.

Anyway, it requires looking at the callstack for each processor which obviously you can't do it BSV.

If you upload a dump file I can try to explain some things for you.

I'm sure you know what a video TDR failure is?

To me, what you've described looks like numerous causes, mainly drivers.

mikeyjames · 08 Jun 2014

Hi Thedoctor,
Thanks for taking the time to explain this. it all started this time after I tried to enable hibernation last Sunday and the system crashed - still happens each time I try and enable it.

I have done the usual stuff - disk check, scannow, etc and no errors come up. But each time I try and enable hibernation the system crashes.

I appreciate your offer of helping but I'm going overseas for a couple of months next week and haven't got the time to dedicate to it as need to complete a bunch of work-related paperwork before I go.

I may take you up on the offer when I get back - if you have the time then of course

BTW - not a single crash in over 24 hrs now after at least two per day previously.

I think when I get back it's also time for me to bite the bullet and do a clean install.

Cheers
Mick