Archive for the ‘Windows’ Category

Installing MyTomTom (TomTom HOME) on Windows XP x64

April 27, 2012

For my sins, I run Windows XP x64 on my main desktop.  One day I’ll jump on the Windows 7 bandwagon, I promise.  While recent improvements with Windows 7’s x64 editions (and the removal of x86 versions from the Windows Server range) has led to more hardware/software vendors writing with x64 in mind, from time to time I’m still left with devices that are not supported.

Case in point, my TomTom GPS device recently decided to pack up and stop working, thanks to a leap-year bug which prevented it getting a GPS signal (really? We’ve only had leap years for about 2,050 years, now).  And so a mandatory update was forced on me, which required me to connect it to my computer for the first time in—er—ever.  And would their updating software install?  Would it bollocks.

Four hours later, I’ve got a working Vista x86 VM running (it was the only 32-bit DVD I had! I’m amazed it still worked with all those coffee cup rings on it), and am installing the TomTom software, when I notice it take a lot longer on one particular step than it did before.  And that step was the running of DriverPreInstall.exe.  Which was in a folder named win32 (in particular, %PROGRAMFILES%\MyTomTom 3\Driver\win32\DriverPreInstall.exe).  This got me wondering, was there a matching win64 folder?  So I went looking and, lo and behold, there was (specifically, %PROGRAMFILES(x86)%\MyTomTom 3\Driver\x64\DriverPreInstall64.exe).

So I ran that DriverPreInstall64.exe file and it told me that it was missing a DLL.  That DLL was DIFxAPI.dll, and it’s part of the Windows Driver Kit (freely downloadable from Microsoft). 

This comes down as a 600MB ISO file, which you can open with most compression tools (like 7-zip).  Open that ISO file and navigate to the WDK folder, then open the file (also in 7-Zip). There, in that archive, there is a file called _DIFxAPI.dll_00000. Drag that file into the %PROGRAMFILES(x86)%\MyTomTom 3\Driver\x64 folder and rename it to DIFxAPI.dll.

Now, run the DriverPreInstall64.exe file and the driver will install. You’ll get the standard warning about the driver not being certified, but you can continue anyway without issue. Now you can connect the TomTom up to the computer by the USB cable and it should install properly. If not, open Device Manager, right-click the TomTom node (it will probably have a question mark against it) and choose Update Driver. The driver should install (it may prompt you again with the certification warning).

Now you should be able to open the MyTomTom3 software (either via the Start Menu or by running the MyTomTomSA.exe directly), and Robert’s your mother’s brother.

Alternative to %RANDOM% in Windows batch files

January 3, 2012

So, it turns out, the %RANDOM% environment variable isn’t random. It’s very much time based. On my XP box, it appears to generate a number that changes every second. What’s worse is that it’s very much deterministic — in most cases, the generated number will be 13 greater than the last number generated.

Not that I was using it for anything crypto-related, you understand, but the time-based thing does present a problem if you are using it in Scheduled Tasks. Particularly if you are using it to create unique, random temporary file names in two Scheduled Tasks that run at the same time.

Of course, this isn’t news. It’s an old new thing. But it was new to me and caused me to screw something up that I shouldn’t have and so on and so forth

Instead, we should pull random data from the system entropy, akin to *NIX’s /dev/random device. After doing some digging, it appears that what *NIX ‘stores’ in /dev/random, Windows ‘stores’ in the registry, a binary Seed value in the HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\RNG key. Of course it does.

We can get to that in Windows batch files, with the REG.EXE command-line utility, usually found in the C:\Windows\system32 folder):

"%SYSTEMROOT%\system32\reg.exe" query HKLM\Software\Microsoft\Cryptography\RNG /v Seed

That gets us some version info and the binary data, in some nicely-formatted table, e.g…


    Seed        REG_BINARY      CC577B9D245DB08D34EC20C75B80CDF36822ACFB13F3FAD640F426948F5A05F1E9C956A8DB58F565CC6A1D2A947F93B38DA425D02D49BF30622FD8E7CFDBF63366A2357361C76ABA68720A04F28E7C4D

…which we can parse with FOR /f and convert to a similar 0-32767, like so:

FOR /f "usebackq tokens=3 skip=4" %%A IN (`"%SYSTEMROOT%\system32\reg.exe" query HKLM\Software\Microsoft\Cryptography\RNG /v Seed`) DO SET RND=%%A
SET /a RND=0x%RND:~0,4% %% 32768

The environment variable %RND% now contains a random number.

If you need a large quantity of random numbers, you may be concerned with repeated calls depleting the system entropy pool. This is a possibility, of course, but may be mitigated by keeping the last retrieved entropy data in an environment variable, extracting the first two bytes when you need to, removing those bytes from the data and refilling the entropy variable when it is empty. Something like this should do the trick

IF NOT DEFINED ENTROPY FOR /f "usebackq tokens=3 skip=4" %%A IN (`"%SYSTEMROOT%\system32\reg.exe" query HKLM\Software\Microsoft\Cryptography\RNG /v Seed`) DO SET ENTROPY=%%A
SET /a RND=0x%ENTROPY:~0,4% %% 32768

Of course, this doesn’t seem to work on Windows Server 2008 R2 (surprise, surprise), as the HKLM...RNG\Seed value does not seem to exist in the registry (or at least cannot be read by REG.EXE), so I expect that means it doesn’t work in Vista or Win7, either. The closest alternative is the Seed value in the HKLM\System\RNG key, but that does not seem to update after reading, so is next to useless for this purpose.

The only alternative I have in Windows Server 2008 R2 is to invoke PowerShell (which is installed by default on our builds) to get a similar binary value, instead of REG.EXE. While you could instantiate an RNGCryptoServiceProvider object and call GetBytes on a suitably large byte array, it may just be sufficient to invoke Guid.NewGuid one or more times, instead (remembering to escape parentheses properly):

FOR /f "usebackq" %%A IN (`"%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe" -Command [System.Guid]::NewGuid^(^).ToString^('N'^)`) DO SET RND=%%A

That said, if you have PowerShell, you might want to consider doing your script in that instead, if you can get past its awful, awful syntax…

Uninstalling SQL Server 2008 fails with “Value cannot be null. Parameter name: sddlForm”

August 15, 2011

I came across this annoying error while trying to remove SQL Server 2008 from our Windows XP desktop Sysprep image.  I found a Microsoft Connect article which gave some brief but ultimately unhelpful advice relating to an error reading the Group SID when uninstalling FileStream.

That said, it did get me on to FileStream.  Looking through the Detail.txt file in the relevant dated subfolder of the C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log folder, I could see that the error was due to the uninstaller trying to remove permissions on the FileStream share that was created when I installed SQL Server 2008, originally.  From Administrative Tools >> Computer Management >> Shared Folders >> Shares, I tried to add the correct group permissions to the {INSTANCENAME} FileStream share, but it didn’t seem to make any difference to the uninstaller.

In the end, I got around it by editing the registry.  Opening regedit.exe from the Start >> Run window, I browsed to my instance’s registry branch, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10.{INSTANCENAME}\MSSQLServer and renamed the FileStream key to something arbitrary (I used “__FileStream“, but I expect you could use anything the installer wasn’t expecting).

Now when I ran the uninstaller, it couldn’t find the necessary registry branch, so assumed FileStream was uninstalled, skipped right over the step and completed successfully.  Then, I right-clicked the {INSTANCENAME} share in Computer Manager and clicked “Stop Sharing”.

I will post if I experience any issues with the desktop image, having performed this workaround.  In the meantime, hope this helps someone out there.