|
sorry to hear that's still giving you trouble.
take your time. i don't want to rush you into anything.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Exactly.
Unless dealing with faulty hardware or bad drivers, it's literally been years I've seen a BSOD that the OS could be blamed for. Dare I say, these days I don't see Windows outright crashing/freezing any more frequently than some Linux distributions...
|
|
|
|
|
+1 to the no BSOD club here. I haven't had any at all in Win10, and I code in VS2019 Pro (Knocking on some serious wood here). 2 years ago, I did have a workstation class motherboard die on me. Likely was around then was the last time I've seen a BSOD in Win7. Drivers can cause this as well. But I tend to buy quality hardware that seldom suffer those issues.
|
|
|
|
|
Two of my users regularly still get BSODs.
I do know exactly why though for these two machines.
Whenever M$ update their handling of graphic devices, the vendor provided drivers for the graphic devices on these two (out of 20 odd physical machines) shut down and bang BSOD.
Of course, what we see on the screen gives absolutely no clue that this is the reason, just learnt the hard way.
Management asked me if we could invoice M$ for the several hundred hours of research I had to do to find the issue and document it sufficiently that someone else can recover these machines if I am not on-site. I suggested that this would only cause amusement in the the house of small soft things.
|
|
|
|
|
Good finding man! 
This is so tricky.. :/
That's one of the reason I like mainstream hardware ... i.e. Intel (apparently AMD might be a good bet now) and NVidia...
|
|
|
|
|
charlieg wrote: My customers do not and will not tolerate their machines crashing for inexplicable reasons
Kopy better codz?
|
|
|
|
|
I didn't much like Win 10 when it came out: compared to Win 7 it was ugly, dull, and schizophrenic.
And yes, it still is all of those things.
But ... it doesn't crash on me, or anyone I support - no BSOD, no nothing. Some apps do, from time to time but that's not the OS's fault.
In all, it works. And when it runs on hardware that is designed to support it (like the Surface) it runs very well indeed. considering the number of different hardware combinations it has to work with, it's a small miracle that it ever manages to boot up, much less actually run!
Sorry - but in my experience, it's pretty reliable these days. Even if updates can be a PITA.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have seen it twice, once on my own Laptop, once on my colleague's. Both times Windows 10 somehow did its magic and voila no more BSOD. No looking up how to fix BSOD.
|
|
|
|
|
Mine doesn't crash. I've got an app that does (and it is because of driver issues), but the OS itself works fine. It even updated from 1803 to 1903 without a hiccup, and speedily, too.
|
|
|
|
|
The only issue I faced on my latest machine was the mouse would do this weird stuttering and hang up for a second, appeared t happen randomly. I don't know how many sites and pages I looked at trying to get to the bottom of it. I even though for a while it was certain areas on the mouse pad and the optic sensor etc. etc.
In the end, I removed the Logitech Unify USB dongle and paired the mouse (Logitech MX Master 2S) via bluetooth instead and the problem appears to have now gone away.
|
|
|
|
|
Just for info: I had a similar problem with a unify dongle - so much so that the keyboard would freeze too. Moving to a bluetooth mouse fixed the problem.
Having done a lot of reading and then experimenting, it turns out that the dongle's communication can be disrupted by WiFi signals and other Rf emissions. I relocated the dongle from the PC under the desk to a USB 3 hub that sits nearer to the keyboard and mouse than any other device that uses radio etc, and now it works fine.
|
|
|
|
|
Cheers, I'll keep that in mind if I go back to the unify dongle for any reason.
|
|
|
|
|
Once upon a time, support.microsoft.com was a technical support site worth it's weight in gold (it really worked, just input the error message and you got the right answer 99% of the time).
Then microsoft decided that everything had to be powered by Bing...
So now it's completely dysfunctional, and aimed at users instead of tech support.
|
|
|
|
|
Jörgen Andersson wrote: Once upon a time, support.microsoft.com was a technical support site worth it's weight in gold
What does a technical support site weight anyway?
|
|
|
|
|
Spot on. 
|
|
|
|
|
See? The support site now is worth its weight in gold.
|
|
|
|
|
|
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)?
Good luck.
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.
Why?
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?
USe Verifier.
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.
|
|
|
|
|
I've used VMS, Ultrix, Solaris, SunOS, HPUX, and AIX and they have never crashed on me.
"Windows the windows way" - huh, expand that a bit if you would not mind. I don't do Unix to my laptop, so....
Charlie Gilley
<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
|
|
|
|
|
I guess that you prove my point.
|
|
|
|
|
I left the M$ hell for living in the golden Apple cage 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Are you shure you have a legal copy of Windows? 
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
lol, yeah I'm sure.
Charlie Gilley
<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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
