RtlVolumeDeviceToDosName(HDD) generates Floppy error

Hi all,
I’m seeing a very weird behavior when calling RtlVolumeDeviceToDosName().
I’m working on a win2k machine with SP4+Rollup1 and all updates installed.

When my driver calls RtlVolumeDeviceToDosName() for the system disk I get the following error window:
“There is no disk in the drive. Please insert a disk into drive A:”

When the error window popped-up, I listed all the system threads using WinDbg and found that the following thread is responsible for this error (Sahara is my driver):
ChildEBP RetAddr Args to Child
f403b120 8042c2ad 8188f3a0 8188f558 8188f588 nt!KiSwapThread+0xc5
f403b148 80433500 8188f588 00000011 8188f300 nt!KeWaitForSingleObject+0x1a1
f403b178 804336b4 e1e04b40 e1e04b40 f403b1e0 nt!LpcpRequestWaitReplyPort+0x52e
f403b190 80494626 e1e04b40 f403b1e0 f403b1e0 nt!LpcRequestWaitReplyPortEx+0x1e
f403b35c 80494aa3 c0000013 00000001 00000001 nt!ExpRaiseHardError+0x23e
f403b3cc 804241bb c0000013 00000001 00000001 nt!ExRaiseHardError+0x14d
f403b410 8042f651 816953a8 00000000 81790910 nt!IopRaiseHardError+0x105
f403b448 80069fbc 00000000 00000000 f403b460 nt!KiDeliverApc+0xed
f403b448 80069c98 00000000 00000000 f403b460 hal!HalpApcInterrupt2ndEntry+0x31
f403b4d4 bef9eeb3 814ef6a0 816953a8 f403b8a4 hal!HalRequestSoftwareInterrupt+0x30
f403b510 8041dded 814ef6a0 816953a8 816953b8 Fastfat!FatFsdCreate+0xbb
f403b524 804bf978 804824e0 804beeba f403b828 nt!IopfCallDriver+0x35
f403b6b4 80450893 81790910 00000000 f403b76c nt!IopParseDevice+0xabe
f403b72c 804d59a0 00000000 81890600 00000040 nt!ObpLookupObjectName+0x4e7
f403b83c 8049f9f1 00000000 00000000 00000000 nt!ObOpenObjectByName+0xc8
f403b918 8049f596 f403bac4 00100001 f403ba5c nt!IopCreateFile+0x407
f403b960 804a8279 f403bac4 00100001 f403ba5c nt!IoCreateFile+0x36
f403b9a0 80464f84 f403bac4 00100001 f403ba5c nt!NtOpenFile+0x25
f403b9a0 8042fe9f f403bac4 00100001 f403ba5c nt!KiSystemService+0xc4
f403ba30 804e8b43 f403bac4 00100001 f403ba5c nt!ZwOpenFile+0xb
f403ba90 804e8e7c 814fd968 f403bac4 00000041 nt!OpenDeviceReparseIndex+0x109
f403bac8 804e9138 f403bd50 f403bd58 f403bd48 nt!FindPathForDevice+0xcc
f403bd60 bff68464 81872030 815e9120 f403bda8 nt!RtlVolumeDeviceToDosName+0x166
f403bd78 80416bfa 815c3f68 00000000 00000000 Sahara!SaharaGetDosDeviceNameWorker+0xd4
f403bda8 80454a24 815c3f68 00000000 00000000 nt!ExpWorkerThread+0xae
f403bddc 80469212 80416b4c 00000001 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

The weird thing is that my driver is not querying the floppy drive (A:) !
As you can see in the stack, the device that is passed to RtlVolumeDeviceToDosDevice() is 0x81872030.
Here is the device stack:

kd> !devstack 0x81872030
!DevObj !DrvObj !DevExt ObjectName
8189ddc0 \Driver\Diskperf 8189de78
8189d020 \Driver\PartMgr 8189d0d8

81872030 \Driver\Disk 818720e8 DR0
8189f030 \Driver\atapi 8189f0e8 IdeDeviceP0T0L0-2
!DevNode 81875ca8 :
DeviceInst is “IDE\DiskSAMSUNG_SV2042H_________________________PK100-15\32303336314a4e46394230313137_0_0_0_0_0_0”
ServiceName is “disk”

Does anyone have an idea why would this happen?

Thanks,
Shahar

Hi all,
I’ve found that this issue only occurs when the SMS Remote Control Agent is installed.
Does this give anyone new ideas?

Thanks,
Shahar

The only thing I can tell you is that, judging from the description of device stack that you have provided, you are just passing a wrong device object to RtlVolumeDeviceToDosName(). Please note that when it comes to storage devices that are managed by Disk.sys, a drive letter may correspond either to a volume (if the target disk is basic or if it presents itself as one), or to a partition (if disk is removable) - it does *not* correspond to the disk itself. However, when it comes to floppy, things are a bit different - in this case drive letter corresponds to the floppy disk itself.

Judging from description of device stack, what you do here is passing a device object that corresponds to the hard disk itself, either than to volume or partition, to RtlVolumeDeviceToDosName(). In other words, you do things the way you would do them if you were dealing with the floppy. Therefore, the system raises an error. This is why you get this bizzare MsgBox() that gets displayed by CSRSS.EXE - you did not even have to go through all trouble of finding a thread that displays it, because it is obvious anyway…

Anton Bassov