Use ProcessExplorer tool from
www.sysinternals.com.
It will show you all the objects used by a process including reg.keys.
Simple idea for you (I've done that long time ago so it definitely works).
You can still delete the key offline, meaning from another OS load.
Since the system is already deployed to the field you can automate the process:
(below I'll refer to the image you already have on the devices as "big image").
- Create a really small XPe image that would be able to use reg.exe (or regedit.exe) from CMD.
Set the image up so that it uses something like \Windows2 dir for the system folder (so that it doesn't interfere with
your main big image if laid out on the same drive).
- Set up the shell of the small XPe image so that it runs a few commands to load the big image's system reg hive and delete
the specified key (reg.exe supports all the commands you need).
- Deploy this image to the field via your current update transport (DUA? something else?).
- Update boot.ini on the disk (just replace it with a new downloaded boot.ini) so that it defaults to load that small XPe
image.
- Reboot the device.
- Small XPe image should be launched here and run in automated mode (e.g., CMD shell may call to a batch file) the
predefined set of commands to update the big image's hives. Then it should update boot.ini to use the big image's \WINDOWS in a
default ArcPath, and finally reboot.
Theoretically you don't even have to clean up the system and delete the small image afterwards. But if you want to it is also easy
to automate. You just have to add a self-deleting batch file call to the StartUp items of the big image. The batch file should
remove all the temporary files and folders.
License-wise you can use the same PID for the small XPe image because:
- the image is only used in the update, system recovery or repair process.
- the image existence is only temporary during the update.
Does this make sense?
