Wrong display refresh rate after boot when using KVM

Some of my computers are connected to the same monitor, keyboard and mouse through Belkin KVM switch. Everything works generally fine except one annoying problem. When one of the computers boots and it is not the active one on the KVM, Windows decides that it is connected to "Default Monitor" and sets the refresh rate to the lowest possible one. Curiously the screen resolution is not affected. The end result of this is flickering and distorted screen that are really irritating. Since I discovered the problem I have heard from a few people that they encountered it with different Belkin KVM models.

To manually fix this issue I had to do the following

1. Open Device Manager and select "scan for hardware changes". This resulted in my monitor being recognized.
2. Open display properties. At this point it shows incorrect high refresh rate even though the actual one is low.
3. Change refresh rate to any value. This will synchronize the dialog with reality.
4. Change refresh rate to the desired value. This will finally bring things back to normal.

This was clearly too much so I decided to automate this process. What I needed were command line tools that could perform the two operations described above: refreshing hardware list and changing screen resolution. Fortunately both exist and I didn't have to write them. The first tool is DevCon from Microsoft. This tool is described by MS as "command line utility alternative to Device Manager" and it can do much more than just rescan hardware list. For the second task I have chosen to use ChRes utility (there were a few others available but this was the first I found).

Collecting it all together I created an "Adjust Screen.cmd" script with the following contents

@echo off
devcon rescan > nul:
chres 1024 768 32 85 > nul:
chres 1024 768 32 100 > nul:

I've put it on my desktop and now all I have to do is to double-click it and wait for a few seconds.

Back to top

---

Show all devices in Device Manager

Windows device manager tries very hard to hide the fact that Windows keeps information about any piece of hardware you ever connected to your computer forever. Remember that old buggy cable modem you used 2 years ago? It is still there in registry just in case you would use it again. Usually this is not a big deal unless of course it is. Quite a few times I've seen various problems arising from this issue. You may get an old driver for a new hardware, hardware refusing to work or any other weird symptoms. So sometimes you really want to see what devices Windows knows about just to be able to delete obsolete stuff. To do so just define the following environment variable

devmgr_show_nonpresent_devices

As a system environment variable and set its value to 1.

Back to top

---

Windows update hangs or displays 0x80240036 error

There are tons of sites that try to help with various and assorted issues with Windows Update/Microsoft Update but I couldn't find anything about this particular error. When I tried to scan for updates the progress bar blinked for a very long time. Eventually it would tell me about the error 0x80240036

As an aside note it looks like each version of Windows Update is getting buggier and buggier. And of course whoever decided that the only hint of what went wrong should be a cryptic error code should be fired IMHO

What I've noticed in this particular case was that the "Automatic Updates" service in Services MMC console was showing its status as "stopping". Now normally service do not stay in "stopping" state for more than a few seconds so obviously this one hang. Of course the "wonderful" Services applet doesn't allow the user to do anything with a hanged service so I had to use the Swiss army knife tool of Windows process management -- Process Explorer. At least the Service applet had shown me the service command line C:\WINDOWS\system32\svchost.exe -k netsvcs. The newer versions of Process Explorer can show command line directly in the main window so it is easy to find this one among many other copies of svchost.exe that are running.

Another aside note. It seems that Microsoft makes more and more of their services as DLLs hosted by svchost. Why do they do it is a mystery especially given the fact that they don't document this approach to other programmers.

So I killed the process, then started the service again and Windows Update started to work again. What kind of moron writes an application that cannot detect such a simple thing as a crucial service being dead??

Back to top

---