Problems
Wrong drive letter for a short moment
When a drive is attached then it usually comes with a drive letter which (if required) USBDLM changes at the earliest possible point. If an application reads the drive letter at the same point then it gets confused when USBDLM changes the letter a millisecond later. This is a very rare problem since most applications use a later notification.
To fix this problem, after removal of a drive, USBDLM can create a registry entry which makes a drive come up without a drive letter assigned next time, so, USBDLM can assign one then and no one gets confused. But this is usually not required.
[Settings]
DeleteLettersOnRemoval=1
Since V4.8.6 USBDLM tries to mess with the Windows mount manager by writing a no-letter entry on disk arrival, a moment before the volume arrives. This works good up to Windows 7. Windows 8 is too fast. At least USBDLM can delete the wrong letter a bit earlier than before.
USBDLM service starts to late
Since XP Windows does not delay the user logon until all services are started - the illusion of a fast system start has priority...
So it can happen that the user get logged on before the USBDLM service is started. In result network drives might fail to create if their drive letter is used and USBDLM starts too late to fix this.
Since V4.5.1 USBDLM can delay the execution of AutoRuns and the loading of the Windows Explorer until it is started:
[Settings]
DelayDesktop=1
This works very simple: On logoff of the user USBDLM creates a RunOnce entry in the Windows Registry which starts the USBDLM.EXE with a special parameter. This USBDLM instance then waits for the USBDLM service reaches status "STARTED" and ends. Afterwards Windows continues with the normal startup process by starting the Windows Explorer and executing all the auto startup stuff. The startup might feel slower then but in fact it is just a different loading order.
Windows Explorer fails when deleting a folder under XP
This is one of many issues when a drive is mounted into an NTFS folder, it's not a USBDLM issue. Please read "Mounting to NTFS folders".
Drive letters accidental reassigned
Drive letters removed by NoMediaNoLetter or when drives are mounted into NTFS folders are reassigned when the "U3 launchpad" (the U3launch.exe on the fake CDROM drive or installed in C:\Documents and Settings\All Users\Application Data\U3) is started. It's an eternal bug in the U3 software. USBDLM since V4.3 can try to fight this when configured:
[Settings]
FightU3Bug=1
But it's not 100 percent reliable.
A more strong option is
[Settings]
ForceNoMediaNoLetter=1
Another software which is known to assign drive letters is "Secure Storage Device SDK" (SSDService.exe) from MXI.
Cannot delete or replace the USBDLM.EXE
While the Windows Event Viewer is open, the USBDLM.EXE cannot be deleted or replaced. This is by design.
Devices which failed to start under Vista, Windows 7
For USB removable drives Vista and Windows 7 always install a "WPD File System". WPD is "Windows Portable Device", a programming interface for devices like MP3-players, mobile phones etc. Since Windows 7 the entries are found under "Portable Devices" in the Windows Device Manager.
If a USB removable drive has no drive letter (no matter if it was USBDLM which removed it or the Windows Disk Management), the start of the associated WPD device fails with "Code 10". This is ugly but no problem - the drive works anyway just as a drive.
If you just want to get rid of the WPD stuff, you can deactivate (or set to manual start) the "Portable Device Enumerator Service" (WPDBusEnum). A nice side effect is that the Windows Media Player stops then synchronizing with USB mass storage devices.
Since Windows 8 the problem is fixed.
Vista / Win7 / Win8 Virtual Store
The "User Account Control" (UAC), introduced with Windows Vista, denies write access to system critical data even to the admin which includes all files under "C:\Program Files". Therefore programs which want to write to an INI file located there would have a problem. Microsoft's solution is to redirect INI files to the "Virtual Store" which is a folder under the current user's documents folder, e.g. C:\Users/(UserName)/AppData/Local/Virtual Store/Program Files/(Program).
Windows creates a copy of the original INI file on first write access. As a result, there are multiple INI files, the original and one for each user.
If an INI file exists in the Virtual Store then this one is used when accessed by a logged on user.
The USBDLM service is not affected by the UAC, therefore it read from its own folder. But the user who edits the INI file is redirected to the Virtual Store...
Since V4.3 USBDLM shows a warning balloon tip if a USBDLM.INI is found in the current user's Virtual Store. A click on it opens the Virtual Store's folder in the Windows Explorer.
Solutions:
- never forget to edit the USBDLM.INI as a real admin ("elevated", "As Administrator"), since V4.7.3 there is the _edit-ini.cmd to do so
- install USBDLM into a different folder, e.g. C:\USBDLM or C:\Tools\USBDLM. The Virtual Store deals with "C:\Program Files" only. In this case remove write access rights to this folder for non admins!
Windows 2000
When a drive is attached for the first time, then it appears in the system, then it disappears and appears again. Since XP USBDLM can deal with it, under Windows 2000 some workarounds are required. If the workarounds fail then the balloontip and AutoRun might be skipped or executed twice.
TrueCrypt drives
Drives used as TrueCrypt containers can be detected as such only as long as they are not mounted by TrueCrypt. This is because TrueCrypt takes exclusive access to the drive so USBDLM cannot read test data. This is a problem for UsbDriveInfo only and when the USBDLM service is restarted while a TrueCrypt drive is already mounted. It is detected then with a DeviceType ReadSharingViolation instead of TrueCrypt. Read more in section TrueCrypt.
Error 193
If the start of the USBDLM service fails with error 193 (which is ERROR_BAD_EXE_FORMAT), then something is wrong with the USBDLM.EXE. Either is in a folder which cannot be read by the "SYSTEM" account which is required for a service being started by the Service Control Manager. Fix it by giving "SYSTEM" at least read+execute access. Or you try to use the x64 USBDLM.exe under a 32 bit Windows.