The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Back in the days while I was at Intel, we used to debug BSODs to figure out what was going on. Now, I was no expert in it at all, but mate who used to sit right behind me was a full-timer on this front. Most of these BSODs were either caused by a product that we sold (and therefore we were trying to resolve the issue), or was to prove to someone (like a laptop manufacturer) that it wasn't our product that was causing the BSOD.
Having said that, I've not seen a BSOD in a very very long time. On the odd occasion where I witnessed one, Windows core dumped gracefully and restarted like nothing happened.
It is a driver, however about 30% of BSODs are due to Microsoft code failing.
Microsoft did tighten up the rules post XP, with mandatory driver signing, which requires qualification, however they relaxed this for windows 10 allowing 'attestation signing' which means the faulty driver can be identified and the company named and shamed.
So, you want to analyse a BSOD? You open in in Windbg, you load Microsoft public symbols with the symSrv command (look in help)?
It is almost impossible. Why? It is very rarely a simple crash once a driver has got this far in its development cycle, and very often, the driver named as the culprit isnt.
Because driver x can overwrite an array, and hit driver y's memory. Driver y runs once every 3 hours. When it does it crashes and is blamed.
So, what can you do?
Turn on basic checking (pool, locking misc checks etc, ie not the low resource simulaiton ones) and then verifiy, one at a time, non microsoft drivers.
What Verifier does is pad each chunk of allocated memory with a check pattern, so if a driver over writes its memory, it can be caught.
It checks for accessing paged out data at elevated IRQL (such as timer expiry, or interrupt) and crashes the driver. (A page fault might not fault if the memory is still paged in. It will only get unpaged if resources get tight. Verifier will catch this bug immediately).
Because it is resource heavy, you can only verify one driver at a time.
Hopefully it will crash, and give you the correct culprit. You can then go slap that company round the head with the now very readable BSOD.
Like several others have told already: I haven't seen a BSOD for ages.
Then, I'm thinking back on a job switch I made a number of years ago:
I left a job where the main development OS was Solaris (it is so long ago that Linux wasn't yet very widespread). I made my workstation crash all the time. Even more often, emacs locked up completely, and we usually used emacs in full screen mode, so the only alternative to rebooting was to go to a colleague and ask if he could do a remote login to my machine and kill the emacs process. My colleagues were slightly annoyed by all my crashes and hangs; I was the only one experiencing it. I gradually learned several different actions that would hang either Solaris or emacs, and showed it to the R&D gurus. They screamed up: But you can't do that! Every fool must know that that will cause a hang! ... This happened not with a single set of operation, but several different cases. I became known as the fellow who did silly things to make the machine hang - the blame was mine. People who know how to handle emacs and Solaris would never behave that way. If only I could learn the same behaviour, I would see that both emacs and Solaris are rock solid software that never causes problems.
I no longer remember which "misbehaved" operations I did, only that they were old habits from a previous job, a different editor and OS where the operation were perfectly normal and valid. When I quit that Solaris/emacs job, I moved to another OS that I knew quite well, as a quite stable system. But not here! This was a timesharing machine, a supermini, with 15-20 simultaneous users. It crashed almost every day, and 15-20 people lost some of their work and had to wait until the system supervisor had restarted the machine. I soon discoverd that the supervisor was a Unix fanatic; he had done whatever he could to make this non-Unix system behave and look as if it was Unix, and he managed it according to Unix guidelines, not according to the vendor's guidelines. I stepped in as a "junior assistant", intended to be a small left hand activity, but I soon took over all operations, doing them the proper way (for that OS). Within two weeks, the machine was running smoothly. Three months later, someone was - from old habit - complaining about this terrible machine that crashed all the time, and I had to drag him over to the logs to show him: It has been continously up for three months now, not a single crash since I cleaned up the machine and maintenance procedures! At first he protested, the logs couldn't be right, but gradually he had to accept that the machine was stable.
If a modern Windows machine is unstable, there is an overwhelming probability that it is maintained by some Linux fellow who insist on doing thing the Linux way, rather than the Windows way. People who do Windows the Windows way have stable machines. Even if you won't find all tools in CLI versions, even if the normal way of operation is using dialogs, trying to force it into Linux look will fail.
It goes the other way as well: Trying to do Linux the Windows way causes lots of problems, sometimes hangs and crashes. If you are going to work on Linux, learn the Linux way of doing it. Even if you have to set your mind back to the 1970s with regard to user interface. It is better to have a stable 70s style machine than a crashed one - and you will have to learn the 1970 style in any case.
Microsoft's pathetic excuse for an operating system.
I have been using Windows for something approaching 30 years, and have had very few problems with it. Rather than "pathetic excuse", I would say it is an excellent operating system and can largely be used without problems by any non-technical person.
However, should you start to mess with it (as I have done once or twice) do not be surprised if it crashes occasionally.
Well off to WinDbg it is. I agree with the assessment of the other sites - huge amounts of adds and "we suggest you download easydriverfix.exe". As for Microsoft's sites, they are just a shadow of their past filled with ridiculous MS responses.
As for Windows 10 itself - the most stable OS for me was Windows 7, and I still believe that Windows 10 was more marketing than anything else. I cite the asinine decision to forcibly reboot computers to update them. Even running W10 Pro, I still see the same issues that people have been fighting since Windows 8. At any given time, the ntoskrnl will be sucking up 10% of my cpu. Recovering from sleep mode is a guaranteed BSOD bomb waiting to detonate. And God help you if you get happy with USB devices. These are chronic issues that have existed in Windows for years, and yet the OS is still vulnerable to the whims of 3rd parties.
Even now after all these years, the most likely way to reset your machine to a stable state is to re-install Windows. Don't even get me started on its security issues.
Anyway off to WinDbg....
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Even now after all these years, the most likely way to reset your machine to a stable state is to re-install Windows
I would make the case that this is true for any OS, unless you're intimately familiar with its internals and know where to look for crap that doesn't uninstall itself cleanly.
There's always one recurring theme I see whenever people bring me a system that's in such a bad state that there's no recovery option but to nuke/reinstall: Users have installed so much software of dubious origin over years and they can't identify a quarter of the items in the Add/Remove Programs list. The first thing to do given a brand new machine is to remove all the third-party bundleware. I've had fewer problems manually cleaning viruses off of people's machines.
Funny you should be advocating for Debian. I've just installed 10 in a new VM, and its GUI-based updater ("Software Center", I think?) insists I'm offline and it can't get anything. Yet I'm browsing the web and other systems within my LAN.
I've used plenty of versions before that, and have used plenty more alternative distributions (see below - this is from my Hyper-V host running nothing but Linux VMs)...yet this is the first time I've encountered this, and I frankly I don't know what to do about it.
I worked on a product that automated data centers. It ran under that flaky, unreliable, constantly crashing, BSOD producing OS called Windows. It ran for nearly 4 years without being powered off, shut down or rebooted even once. Then the machine was upgraded to a newer version of Windows and continued without issue until I left the company quite a bit later.
We also had to deal with AS/400s, various Unix and Linux machines and they were, relatively speaking, constantly hanging up or giving problems. In fact, we used our software - running under Windows - to report when these other machines became unresponsive.
This was a few years ago but I still haven't seen a BSOD except just one about five years ago when some memory hardware failed.
Sorry, but I don't intend to join your hate-speech club!
- I would love to change the world, but they won’t give me the source code.
I had an old Dell 6520 that lasted me for 5+ years. Then one day it started to BSOD on me at random intervals. the BSOD messages were all different. I checked on the "usual" places for answers the BSOD message but no help. I finally decided to run a memory test, (MemTest86[^]) and low and behold, I had some bad memory. Replaced the memory modules and all was good.
Last Visit: 24-Jan-20 21:35 Last Update: 24-Jan-20 21:35