Stefan Klein wrote, on 12.04.2008 21:07:
When i delete this key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FDC\GENERIC_FLOPPY_DRIVE\4&33bc18fa&0&0]
it reappears after reboot as if embedded would reinject that regkey at
every boot.
The regkey mentioned above is versatile and computed at system startup.
It's normal that it vanishes after reboot. The really important one is this:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware
Profiles\Current\System\CurrentControlSet\Enum\FDC\GENERIC_FLOPPY_DRIVE\4&33BC18FA&0&0]
"CSConfigFlags"=dword:00000000
Setting 'CSConfigFlags' to '1' will de-activate the device after reboot
or if you enable/disable a state in device manager it will remain locked
to 'disabled'. So Windows Embedded is not able to change the key though
it reads and processes it if present.
Who's in charge for that key?
'Services.exe'. There are only two visible services in my XPPro system
that are associated with services.exe. 'Event Log' and 'Plug&Play'. I
bet my money on 'Plug&Play'.
Plug&Play is working fine but the device manager is still not running
properly.
'Plug&Play' is just half the truth. The actual process of disabling
hardware devices is not about setting registry keys. Its about using
APIs like 'SetupDiCallClassInstaller' so that CoInstallers or .inf
scripts can be parsed properly for de-/installation. These functions are
part of setupapi.dll. I don't know why these functions won't be properly
invoked in windows embedded. Maybe some prerequisites (regkeys?) are
missing.
I checked dependencies of devmgr.dll, setupapi.dll and services.exe.
'Query.dll' and 'mobsync.dll' were missing. I copied them manually to
the target system without any change.
The setupapi.log (set to max verbose) doesn't give any usable informations.
Maybe it just needs one more component from target designer. Not sure if
its possible to trace down APIs up to setupapi.dll.
