|
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
|
|
|
|
|
A copy of Windows crashing this much shouldn't be legal. :-p
|
|
|
|
|
charlieg wrote: 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.
|
|
|
|
|
Richard MacCutchan wrote: I have been using Windows for something approaching 30 years
Had you mentioned the 30 odd years of *nix usage before that, you'd be showing your age. Jeez, man. That was close.
|
|
|
|
|
Sadly I came to Unix rather late in life, in fact after I started on Windows. The previous 25 years were spent working on mainframes.
|
|
|
|
|
Install Debugging Tools for Windows and use WinDbg to open dump file after BSOD. Don't believe to any BSOD diagnosis site.
|
|
|
|
|
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....
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
|
|
|
|
|
charlieg wrote: 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.
|
|
|
|
|
I've only had one BSOD on Windows 10, and it was caused by, ... wait for it ..., a bad driver! It really was! Vendor site had an updated driver and haven't had a problem since.
|
|
|
|
|
I've had the opposite happening to me.
Laptop nagging me to update the drivers, did it and it bluescreened on startup. It was hell to rollback.
|
|
|
|
|
charlieg wrote: what are your preferred sites?
Amongst these you will easy your burden.[^]
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
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.
C:\> (Get-VM).Count
137
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
