Not to be left far behind by WDK releases from Microsoft, I switched from Windows Server 2008 RC0 WDK (build 6001.16659) to November Community Technology Preview (CTP) build 6001.17042 last week. First I uninstalled the RC0 WDK and documentation and got prompted for reboot. However post reboot, I found that the uninstaller left dead shortcuts in my Start Menu.
Since the shortcuts created by the installer are in the All Users area (typically C:\ProgramData\Microsoft\Windows\Start Menu in Vista or C:\Documents and Settings\All Users\Start Menu in XP), one can clean them up manually by simply deleting the shortcuts in Windows Explorer. Except in this case, they are used and hence locked by explorer.exe preventing deletion. My options were to do a pending deletion that would necessitate a reboot, or try killing explorer.exe, delete the shortcuts in command prompt and restart Windows Explorer. You can guess which one I tried.
The CTP 6001.17042 WDK and WDK Documentation installations went smooth. After successful builds without any major errors or warnings popping up, it did feel like an easy switch until I fired Signtool to sign the drivers. The thing barfed saying Signtool requires CAPICOM version 2.1.0.1 or higher etc. as shown below.
I wanted to first find out and make sure Signtool.exe was being executed from the correct path. Vista has this nice where command just for finding which directory (from all directories in PATH environment variable) is the source of the executable but I was on XP. Regular search for Signtool.exe under the WDK root directory found 2 identical copies of Signtool.exe, one at \bin\catalog and the other at \bin\SelfSign. Then I checked my PATH environment variable for either path and found \bin\SelfSign in there (\bin\catalog was not in there at all).
Now it was time to check where capicom.dll was coming from given that I was executing from SelfSign directory. The capicom.dll in that directory turned out to be 2.1.0.2 so clearly it was not the one that was being loaded. Changed current directory to SelfSign directory to see if that would make a difference, it did not. Then I found a capicom.dll lying in my Windows System32 directory and it was indeed older (2.0.0.3).
After I renamed the old capicom.dll and copied the new capicom.dll from SelfSign directory to System32 directory, COM registration was in order. After registration, Signtool worked. My reason for not registering capicom.dll from SelfSign directory was simple, I wanted other things that might need this dll should continue to pick it from System32 directory even if I remove the CTP WDK. But then I was overlooking that COM can version components easily and can have existing capicom users pick it from System32 while Signtool uses it from its local directory. This would require careful arrangements in registry, which I presumed, did not exist for capicom registrations.
Capicom.dll seems to be strictly part of DDK/WDK install and is not installed as part of Windows XP or Vista. Version 2.1.0.1 of capicom.dll was present in %PROGRAMFILES%\Common Files\Microsoft Shared\CAPICOM directory on the XP box in question. This might be the work of Vista WDK (6001) installer since the same version 2.1.0.1 of capicom.dll also exists (in the same path) on my Vista box with Vista WDK installed. Since the 6001 WDK installer seems to have registered capicom.dll from SelfSign directory on Windows Vista, perhaps it would have been ok to register it from SelfSign directory on my XP box too.
Knowing all this now I dread 2 things –
- Signtool (or something else) in other older WDKs installed on this box will now be loading the new capicom.dll consequently breaking something
- System file checking (SFC) will prompt me to put the XP CD into the drive bay so it can restore a system file.
So who uses capicom.dll from C:\Program Files\Common Files\Microsoft Shared\CAPICOM anyway ? Any takers ?
PS: And where is my XP CD ? 😉
