Well, I got it working, so it is possible, despite what the Microsoft
knowledge base and what both Peter and other Microsoft support people told
me… (I’ve always been bad at listening…)
From a pointer on a newsgroup, I discovered that the NT Resource Kit says
the following:
This topic describes the value entries that can appear in the Parameters
subkey for each SCSI miniport driver subkey in the Services subkey. These
value entries can appear either in the Parameters subkey or in
Parameters\Device#, where the # represents a SCSI host adapter number
beginning with 0. The Parameters subkeys store settings that apply to all
SCSI miniport devices of that type. The Device# subkeys store settings that
apply to a particular SCSI host adapter.
Registry path:
HKEY_LOCAL_MACHINE\System
\CurrentControlSet
\Services
\DeviceName
\Parameters
ScsiDebug REG_DWORD 0x0 - 0xFFFFFFFF
Default: 0
Specifies the level of message detail in DebugPrint, with 0 representing the
least detail. This value entry is used for debugging.
So, setting “ScsiDebug” to the appropriate level in both
\Services\atapi\Parameters seems to work UNLESS you have some specific
settings in the \Parameters\Device# sections. In that case, the Device#
settings – or lack of them – will override the one in the Parameters key.
Thus, if you have the Device# key(s) created, putting the ScsiDebug value in
just \Parameters will not enable it for those devices, that is, it does not
inherit from the key above. This took me quite a while to discover…
There’s no way to get the output without having a debugger attached.
Yes there is – that part is easy. DbgView from
http://www.sysinternals.com/ or DbgMonitor from http://www.osr.com/, and I
think there’s even one in the NT Resource Kit or somesuch.
We would help the customer get a debugger connected to their failing
machine and/or spend lots and lots of time pouring through the crash
dump to piece together what happened.
Yuck!
We’d also try to reproduce the problem locally so we could put
instrumented binaries into the problem system more easily.
That’s not possible in this case since it only happens about one in 500
machine-days. So, we’re running the same debugging stuff on 50 machines and
hope to catch it in 10 days or so.