You'd *better* believe The Man.

An oldie but a goodie.

unless the submitter has two identical machines. Reason being, if the hard disc is swapped into another system there's a fair chance the wrong chipset driver will be provided and the compisite machine will bluescreen.

Even worse would be if the machine starts correctly and then installs its own chipset driver causing bluescreens when the hard disc is swapped back.

My first port of call, before the memory diagnostic and before running SMART tests would be the event log. It's neglected far too much for my liking.

I'd follow that with perfmon, and then offline AV scanners / liveCDs. Then I'd start thinking about burn-in testing and swapping out hardware.

Had a friend's machine in over the holidays. It would boot, get to Welcome screen, then after logging in machine would log straight back out. You weren't able to interact with the system at all.

Tried safe mode - same symptoms. Therefore I was of the opinion that it was a driver, winlogon-hooked DLL or a service that was tagged to run in safe mode.

The WinPE preinstallation environment allowed me to find/remove some of the offending parties, but still no dice. Snagged UBCD and pulled updates for all of the antivirus / antispyware tools.

Booting to UBCD got _some_ results... Spybot found a large number of nasties (including some identified as Antivirus 2009); A-Squared found some, as did AVG. Even after running all of them, the actual root cause persisted. Unfortunately, SysInternals autoruns wasn't much help, as it retrieves startup info from the currently running system, rather than of the inactive o/s (anyone know whether there's a tool that'll do this?)

Ultimately I waved the white flag and pulled out a repair install of Windows to bring the machine back up, at which point I found the culprit - a process called winlogon.exe in \windows rather than \windows\system32 and invoked via the winlogon registry keys. I kicked myself for not spotting this, but also note that none of the scanners in the UBCD (updated as of 28 Dec) were capable of identifying this as foul.

The offending file has been sent to various AV vendors in the hope that this one can be spotted in future.

To be fair, when I receive a really asinine query - one that the user should have been able to solve themselves - I take great pleasure in using either F1 or Google with a couple of keywords that said user has used describing the problem, and - cor, look at that - problem's solved. I used to think that this would give end-users a cluestick to F1 / search the internet before calling. My optimism was somewhat unfounded.

In my experience, it's never a collection of screenshots. It's one screenshot. Usually of the entire screen, not the actual error window.

This is sent via an e-mail client. Since we're in MS land (os/x at a pinch) as evidenced by the use of "Word", then it's a pretty safe bet that whatever e-mail app the user has will support inline images. Instead, they've made you (1) open a word processor to display the image and (2) muck about with zoom settings so you can actually read the damn thing.

Also, what you generally find is that the problem description is in the e-mail, not in the document, so you're also having to juggle windows to work out what's going on.

This happens so often where I work that it just isn't funny anymore.