I am very sorry to see that. In the end, it's SF's loss as they've lost a very talented analyst.
When I was banned from SF, the main analyst there was Mike (Writhziden), with over 11,000 posts in 2 years. He made a write up on debugging and was the one who first showed me how to debug. If you've ever used it, he is the developer of the SysnativeBSODApp for bulk analysis of dumps.
I think the problems at SF weren't helped by the high volume of traffic. At one point, Mike was the only one really doing analysis, hence his crazy high post count and an average post rate of over 30 posts day. That was the reason for the app development, to keep up with the huge demand. Eventually, Mike burnt-out and stepped down from debugging, before he then left. Mike's analysis was never quite as detailed as yours or Patrick's, simply because of demand. He did develop a very good ability to spot patterns and be able to pounce on a cause with only the smallest of hints in the dump, because he was dealing with so many of them.
My analysis was never as detailed as yours or Patrick's, and I never did as much as Mike. Most of what I know came from Mike, and I relied on canned speeches a lot at the start. I still have them all. For a bit of nostalgia, I found my first debugging thread.... Wow... hxxp://www.sevenforums.com/bsod-help-support/233407-bsod-while-streaming-downloading-gaming-mostly-driver_irql-messages.html. I'm cringing slightly - that was just a case of throwing every diagnostic tool I had at it and seeing if something stuck!
My debugging did get better!
IIRC, Mike taught Arc to start with, but obviously since Mike left, Arc has been on his own. Looking around, the only "old" analyst I see is Richc46, who has been there for years. Other than that, all of the ones from my "era" have either left or been banned. SF seems great at attracting great analysts, but can never keep them. H2SO4, Writhziden, FredeGail, JaidynM, Patrick, You, X BlueRobot, JCGriff2, Vir Gnarus and so forth. Most of the BSOD team there now seem to be the "new" generation, and who trained them I am unsure.
I think Richard hit the nail on the head in his post. The aim of SF is to get them in and out as fast as possible, resorting to the quickest way possible. Test the RAM, test the HDD, run Driver Verifier and try and find a faulty driver, stress test and then reinstall. If reinstall doesn't solve it, swap out hardware. Vir Gnarus sums the approach up quite well here:
https://www.sysnative.com/forums/bs...284-blue-screen-of-death-method-and-tips.html
Vir Gnarus said:
5. Interpret, Verify, and Diagnose, in that order - It's easy to jump straight to diagnosing an issue just by the readout given by !analyze -v from a crashdump someone gave you, but be careful. Many things can prevent the data you and the analysis engine see from being accurate and will lead you in the wrong direction. You must first be able to interpret what you see in the first place so you can understand it, then you should verify that the data given is legit and can be used to diagnose the problem. If you fail to follow all three steps in that order, both your conclusions and assumptions will be misleading, and end up causing the user to do stuff they shouldn't have to do to fix the problem, often finishing unsuccessfully.
....
8. Avoid the Caveman Approach - Swapping hardware. Uninstalling software. Changing various settings. Anything that alters the environment with the intent not to resolve an issue but to find an answer is never wise. You often will cause problems for the client later on, and it'll often cause them to be dissatisfied with having a messy PC in the end, even if the problem does somehow managed to get fixed after it all. Granted, there are those desparate times where your knowledge runs short or resources are sparing where there doesn't seem to be any other option, but too often people resort to caveman approaches way too early, effectively giving up on a proper diagnosis and just deciding to go hog wild and make a lot of noise in the process. Ask others for assistance (or knowledge), run tests instead of changing things around, acquire more data, re-evaluate the situation. Do whatever it takes before having it come to this. Though in all honesty, you're probably better off swallowing your pride and saying "I cannot help you" than making a mess of their PC in a vain effort to close the case. If you're determined, ask them first about going this route before proceeding and the ramifications involved.
I know being banned can sometimes be emotional, but they never really welcomed you there anyway. There's plenty more to learn, and plenty more people to help. Keep doing what you do best - helping people.
-Stephen
