Question

I am using WMI to determine when various forms of media are plugged/put in (USB drives, CDs, etc). However, encrypted drives such as ‘SanDisk Enterprise FIPS USB’ do something funky: it looks like they represent themselves as a CD drive from which an unlocking application can be launched. When the unlocking utility is finished, the new USB logical disk is available for read/write. So the order of events as I am seeing them from WMI is:

1. USB is inserted
2. Win32_DiskDrive object is created (see \.\PHYSICALDRIVE2 below)
3. distinct Win32_LogicalDisks are created, one I copied below (G:), and holds the launcher, the other (M:, in my case) is the drive that will eventually be accessable.

BUT, no Win32_DiskDriveToDiskPartition entries exist until after the utility has run, which is the usual way to locate volumes from a hardware ID. After much googleing and some trial and error, I haven’t been able to find an architecturally sound method of associating PHYSICALDRIVE2 to G:. The general consensus online is that you shouldn’t expect such mappings to exist, because physical media need not have partitions or volumes, etc, but in my case I basically know it does exist, and would error out in some meaningful way if the expected mapping were missing.

At this point, my only strategy is to enumerate all the volumes and just look for the appropriate file in all CD drives, maybe keeping track of any such devices that have been recognized after my encrypted USB drive was connected. Obviously this is an ugly hack. Suggestions?

TargetInstance = 
instance of Win32_LogicalDisk
{
    Caption = "G:";
    CreationClassName = "Win32_LogicalDisk";
    Description = "CD-ROM Disc";
    DeviceID = "G:";
    DriveType = 5;
    MediaType = 11;
    Name = "G:";
    SystemCreationClassName = "Win32_ComputerSystem";
};

instance of Win32_DiskDrive
{
    Caption = "SanDisk Enterprise FIPS USB Device";
    ConfigManagerErrorCode = 0;
    ConfigManagerUserConfig = FALSE;
    CreationClassName = "Win32_DiskDrive";
    Description = "Disk drive";
    DeviceID = "\\\\.\\PHYSICALDRIVE2";
    FirmwareRevision = "6.61";
    Index = 2;
    InterfaceType = "USB";
    Manufacturer = "(Standard disk drives)";
    MediaLoaded = TRUE;
    Model = "SanDisk Enterprise FIPS USB Device";
    Name = "\\\\.\\PHYSICALDRIVE2";
    Partitions = 0;
    SerialNumber = "u";
    Signature = 0;
    Status = "OK";
    SystemCreationClassName = "Win32_ComputerSystem";
};

Answer 1

I had a USB 3G dongle that worked in a similar way.

It presented itself to the computer as two entirely separate devices: a CD-ROM drive and a 3G dongle. In your case it’s a CD-ROM drive and a hard drive.

Windows thinks G: is actually a physical CD-ROM drive. G: isn’t a partition of PHYSICALDISK2.

This is why you can’t find a direct connection between G: and PHYSICALDISK2: there isn’t one.

If you dig deep enough you could show that the CD-ROM and the disk are on the same USB bus. I don’t know if you could conclusively demonstrate via software that they are actually the same device.