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.
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.
My preferred solution is a kernel dump and WinDbg. The far most crashes I've diagnosed myself stem from faulty third-party drivers, a couple are extremely specific in being unspecific which indicates hardware failure. I remember one I've seen which was impossible to nail down at first, but dude finally admitted overclocking but couldn't grasp the causal connection between overclocking and kernel panics himself.
Most BSoD events are now hidden from the user, as ms has followed apple's example of freezing the state of the monitor (apple shows a screenshot) whilst frantically killing and restarting stuff in the background.
The only way to see that anything happened is by checking the error log -- but even that only works sometimes, because the error log always seems to be one of the first things that stop working,
Personally, I'd rather get blue screens; who knows how much worse they make things by trying to hide errors?
I wanna be a eunuchs developer! Pass me a bread knife!
The company IT force upgraded the 7 year computer I was working on from 7 to 10, with zero checks why no indicators ever showed suggesting to upgrade.
Came into work to work one day and "oh, oh! Why is the desktop different. Win 10 upgrade."
Check VS and critical daily tools still worked. Cool.
Enable dual screen strecth. Odd - not finding 2nd monitor.
Odd - not finding graphics card.
Install radeon driver update - crash. but not BSOD crash.
Windows very kindly rolled the change back to using default windows graphics driver without completely falling over.
Issue - dell motherboard driver + some releated graphics driver is not supported for windows 10.
And even better is windows detected such a thing and never prompted to upgrade knowing that the hardware was not supported.
Months go buy, zero mention why I'm not using the 2nd monitor.
There was mentions ages ago that all old hardware would be replaced. Even filled out spreadsheet with computer details indicating serial number and model type which 10 second search would indicate age and if Win 10 supported, and said spreadsheet was used to remotely identify my computer for upgrading.
Suffice to say I started looking up articles on why devs and IT do not get along, wanted to find something regarding how a number of Devs write the software IT use and actually end up with a bunch of knowledge to get their work done which they know why not ... blah ... blah ... blah.
I've been building industrial control systems for a good 20 years now, and all based on the windows platform (okay some embedded stuff out there too), and other than hard disk or power supply failure the systems have been rock solid. I still have some XP machines out there just chugging away, and no one want's to upgrade them, if they are still working.
some machines have user interaction, others don't, I've got one machine (at least) out there that hasn't been restarted in close to 10 years, still ticking away with no issues. honestly the only real troubles I've had were do to system admins and IT people mucking about "tweaking" a system, then i get called out, put everything back the way it was, then they tweak it again, so i get called out again....
STOP TOUCHING THE #### COMPUTER!!! YOU DON'T KNOW WHAT YOU ARE DOING!!!
I've had control system's running on every version of windows since XP, the only true reason of the stability is: no windows updates can be installed, because there is no internet at these facilities
Last Visit: 14-Dec-19 0:37 Last Update: 14-Dec-19 0:37