Wednesday, June 16, 2010

Google Earth Installation - Error 0x80040905 on Vista/Win7

With credit to

I recently tried to install Google Earth on my Vista X64 setup, so I could play with Geotagging photos - unfortunately Google Updater kept failing the installation. On an attempt to manually install, the installer bombed out with the mysterious error 0x80040905. Helpful stuff.
On my machine the problem was to do with mapped network drives.
First I checked this webpage for advice - it might help some of you, but it wasn't relevant to my problem as I don't have any existing versions of Google Earth installed. Then I remember an issue with some Adobe installations which had given me a weird 'Invalid Drive' error in the past.
The solution proved to be the same one:

1.Run CMD as Administrator. (type CMD into the start menu, then right click on the CMD icon in the start menu and choose 'Run as Administrator')

2.Type NET USE - you should see a list of any mapped network drives, but they will probably be listed as Unavailable.

3.For each network drive, type the command NET USE M: \\SERVER\SHARE replacing the server and share as appropriate.

4.Just for kicks, type NET USE again to check that your network shares are now up and running.

5.Don't close the command prompt just yet, install Google Earth and everything should go OK.

The reason for this is that in Vista network shares are set up on a per user basis, and the installer is running as Administrator. For more info do some sort of google search like this one.

How to change the Windows 7 Login Screen Background

Thanks to withinwindows for finding out this excellent feature.

Although this functionality was designed with OEMs in mind, it is pretty easy to turn on and off using regedit and some images lying around your hard drive.
First, a check is made to determine if the customization functionality is enabled or not. More precisely, a DWORD value named OEMBackground in the HKLM\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Background key is checked. Its data, of Boolean type, defines whether or not this behavior is turned on, i.e. 1 for enabled, 0 for disabled. This value may not exist by default, depending on your system.
Afterwards, if customization is enabled, the primary monitor’s screen height and width are retrieved via calls to GetSystemMetrics. These values are used in the computation of the screen width (w)/height (h) ratio. For example, my desktop resolution is 1920x1200. The ratio, computed by the division of w/h, is 1.6:1.
The result of this computation is looked up in an internal table that drives what image to load on disk. Although I don’t have a large enough monitor to test, it appears resolutions higher than 1920x1200 will force the loading and zooming of an image of closest compatibility (i.e. same ratio, smaller image).
As this is an OEM feature images are derived from %windir%\system32\oobe\info\backgrounds. Like the registry value, this folder may not exist by default. The following files (sorted by width-to-height ratio) are supported in this folder:

background768x1280.jpg (0.6)

background900x1440.jpg (0.625)

background960x1280.jpg (0.75)

background1024x1280.jpg (0.8)

background1280x1024.jpg (1.25)

background1024x768.jpg (1.33-)

background1280x960.jpg (1.33-)

background1600x1200.jpg (1.33-)

background1440x900.jpg (1.6)

background1920x1200.jpg (1.6)

background1280x768.jpg (1.66-)

background1360x768.jpg (1.770833-)

NOTE: Images must be less than 256kb in size. Thanks for pushing me to investigate, Jay C.

The backgroundDefault.jpg image is loaded and stretched-to-fit when a resolution/ratio-specific background cannot be found. The other resolution/ratio-specific files are self-explanatory. If the background cannot be loaded (e.g. image physically too large, incorrect ratio, etc.), the default SKU-based image is loaded from imagesres.dll. You’ll see a Windows Server-themed grayish background in there, too, suggesting this functionality is not specific to client SKUs.

With credit to