Windows 10: Debugging Tools for Windows 10 Question

You can install the WinDbg tools from the Tools "beta" from here: Windows 10 Technical Preview tools

I haven't done this on my latest Windows installation - but AFAIK it's not an upgrade. Rather it'll be another version installed into a directory on your system (so you can use different versions and can compare them). So, if you use scripts (as I do), you may have to change some paths in order to get it to work with your scripts.

Back in the old days (Win2k/XP) there weren't any BSOD experts for everyday users. The only "experts" were either developers helping out users (cpc2004) or self-taught people (Bill Castner) - and there weren't very many of them. When I started studying BSOD's, I worked at learning how to analyze memory dumps. It was difficult, and took away from me looking for patterns that emerged in the analysis.

In-depth analysis of memory dumps is harder than just using a few commands, and it often doesn't result in any additional information. Long ago we had problems with ASACPI.sys; Daemon Tools, internet security/antivirus/firewall tools/STOP 0x124 errors that didn't show up in the memory dumps. While working on them I determined (for my own use) that I was more able to help if I looked for patterns rather than looking for evidence in the depths of a memory dump. Also, it's harder to get a full memory dump from a user than it is to get a minidump - and back then it was even harder because of storage limits.

So, I stuck with looking for patterns, and have refined that over the years. One pattern that I have noted is that there are 2 types of BSOD topics. Those that are solved in 2 pages or less - and those that go to 4 pages or more. I tend to think that the shorter one's are a result of simple (relatively) problems most often involving a single driver - and that the longer one's are complicated and often are the result of several drivers conflicting.

As for the STOP 0x124 errors - jcgriff2 and I argued with developers for a long time about this. Please note that the STOP 0x124 was never accepted as solely a CPU error, rather it's an error that the CPU sees and then reports to Windows. Unfortunately, the CPU's ability to analyze errors isn't as good as Windows - so the reports are rather cryptic.

But, back in the day (early Vista), it was the majority opinion that the STOP 0x124 error was a hardware error - and only a hardware error. For a long time we (jcgriff2 and I) insisted that the STOP 0x124 error could be caused by things other than hardware. Around the same time the ASACPI.sys driver became a problem in BSOD's. And, through this, we were able to show that drivers could cause this error - not just hardware. After a long time arguing this, it was finally accepted by the community as a whole.

I prefer to state that I am an expert in helping users to fix their BSOD's. And that I am totally unqualified (and unable) to assist developers in fixing BSOD's with their products. The point here is that we're not involved in fixing drivers, but rather we're involved in replacing (or removing) problem drivers with versions that don't cause problems.

EDIT: The downside to the methodology that I use is that it requires a lot of experience. I notice a trend in BSOD analysts towards more memory dump analysis, but that's sorta like doctors/veterinarians doing more tests these days. The tests are more available and can help.

 

Interesting John, we have seen lots of 0x124's caused by software recently over at SF.....predominantly through running beta-Chrome browsers and Gigabyte applications (System Information Viewer and Thermal Monitoring Software).

 

I wouldn't know where to start with a Kernel Memory Dump, I tend to fumble my way round in a much less refined manner such as yours John. I enjoy my victories and try to learn from the ones that really make me use my grey matter, but either way the experience itself is excellent. I've learned a hell of a lot in the past ten or so months that I always took for granted was way beyond my comprehension.

 

Yeah the Gigabyte SIV (among other Gigabyte crapware) at least has the common decency to show a trace of itself in a 0x124. Always appreciated that is.

 

I have got my answer, John. It feels heavenly good that your (jcgriff2 and you) stand matches with that of me. And I will proudly carry this philosophy till I see you posting something else in this topic.

And I try to follow your footsteps.

 

Double ditto. *Smile

 

I find the process of hunting down a cause of a BSOD rather fun. I'm not entirely sure why but I've taken more interest in BSOD analysis than with a lot of other IT subjects that I delve into. I've learned a lot about BSOD's from all of you and continue to do so. *Smile