Alert: ASCOM broken by windows update!


My Deep Sky West imaging partner and I have had issues since last night, first with SGP connecting the the TSX driver and then with PhD guide commands not getting to the mount. According to a post in the past couple hours by Bob Denny on the ACP forum, this is probably caused by the recent Windows 10 update intended to address the much publicized CPU security flaws. This update has been causing numerous issues with ASCOM connectivity. There is apparently a workaround that Bob has published on the ACP forum. If you are having equipment function issues that started in the past couple of days for no apparent reason, this could be your problem.

If you have access to the ACP forum, the information is there. Maybe one of the moderators here could get that information posted here as well.


Could you describe in more detail what PHD issue you were seeing? Thanks.


Initially SGP would not connect to the ASCOM driver for TheSky (Paramount ME). Reinstalling both TSX and the driver fixed that but then PhD would cycle the image but would not guide. It was not getting a response from the ASCOM driver, probably due to the issues with the update.

Of course from other reports, this is in no way limited to just PhD or just guiding.


Oh wonderful :slight_frown: if Bob knows then I’m sure the ASCOM folks are on it. Wonder if my desktop will still get patched as it’s an AMD Ryzen…?



Bob already has posted a workaround on the ACP forum that was apparently suggested by Microsoft.

We will modify our system tomorrow as instructed. Fortunately, it is cloudy down at DSW tonite anyway.


The quick way to get it working again is to uninstall the January Windows 10 update. I did it tonight after spending 3 hours trying to figure out why my Paramount MX+ would not respond to PHD2 guiding commands. Of course Windows is already bugging me about restarting to install the update again. I have until tomorrow to either disable windows update or go through the workaround to get it fixed. At least I was able to get imaging going again tonight!



Well, this probably explains all the issues I had last night trying to get equipment connected through Ascom. I attached the error message that I was getting in sgpro 3.04 when trying to connect my nitecrawler.


My mount OBS computer (Intel NUC) is “waiting for restart” to install this
infamous update. I think I’ll wait…


Thank you for the warning. There is the same warning on the 10 Micron Forum and SGL.

I have applied the work-around/fix described by Bob Denny and am able to succesfully connect everything in my home Obs: 10 Micron mount, MountWizzard, Ascom Observing Hub, MGBox, AAG CW, Solo, AAGCW Safety Switch, Dragonfly, SGP, QSI683 & filter wheel, Lakeside, Flat Man. Scripts are working, camera cooled, filter wheel moved, mount slewed etc.

Without actually imaging (major caveat) it all seems to be OK at this early stage.

Link to ACP page with fix in Windows Services:



More info is surfacing about this issue. It appears it is patch KB4056892 that is causing the problem. If you are running Windows 10, you can uninstall this patch. When doing so, your PC will appear to be doing nothing for several minutes and then you will get the message to reboot.

You might also want to turn on the option to “Pause Updates.” This will stop all updating for 35 days. Time for Microsoft to fix the problem.

I am not currently able to test this on my own observatory PC so I can’t say for sure that doing the uninstall will fix the ASCOM issue but worth a try.



On my Windows 10 observatory PC the patch is KB4056891 and was installed on Jan 4. The night of Jan 5 I lost an entire night of beautiful clear sky because ASCOM failed for both my Digital Domeworks ASCOM dome control driver, and my Gemini 2 ASCOM driver.
Today after noticing this post I uninstalled that patch, and everything works again. I put MS updates on a 35 day pause, the longest allowed. Hopefully MS will fix it within this time frame.


Some further info – a good friend and fellow astronomer is also an experienced COM developer and he says the problem lies in the coding used in many ASCOM drivers.

Microsoft closed a known security flaw in COM and that caused improperly written ASCOM drivers to fail. He does not think Microsoft will make any changes or roll backs and it will be up to the ASCOM driver developers to fix the problem and release new versions.

Apparently not all ASCOM drivers are affected by the patch but it appears that TSX does have the issue, however.

My home system received the KB4056892 (not …91) and it has not affected any of the software I use at home. This patch can be easily rolled back in Windows 10 by simply uninstalling it. The friend mentioned above used the procedure referenced on the DC3 forum discussed earlier and it solved the problem on his observatory PC. I have not seen anyone post whether or not rolling back the update fixed a PC that was failing but it seems like it should. However, that may not be anything other than a short term work around if Microsoft says its “our” problem to fix.



Yes, it definitely appears that the TSX driver might have that issue. Our issue last night was that PhD was unable to get guide commands to the mount, the logs indicate it was getting no response to guide commands from PhD under DirectGuide.

If I understand what you are saying then only those com drivers that are written with that “flaw” (see below, it may not be a “flaw” as such) have the issue (which explains why not all drivers and functions have died)?

Sounds like those developers that wrote the drivers with the issue will need to fix and reissue the drivers unless MS can (or even will) come up with a way around that. If the drivers in question are truly wrong, then MS may not feel that it is their problem and will not deal with it.

We have rolled our system back and it is working but it sounds like the developers have (35?) days to fix their drivers before their users are totally dead in the water.

UPDATE: According to a post by Bob Denny on the ACP forum:

“And the whole thing is a result of some junk DCOM info needing to be present in COM registration just (and only) for TheSky 6 ten years ago! I was around for all of that. Thanks for alerting me to this. I will get onto the SGP forum and fill in the blanks.”

So if I am understanding this, it is all about old code for making the TSX driver compatible with TS V6 so it is less a matter of fixing code but of removing that requirement and it’s code? Probably well past time that TS V6 users ungraded to TSX anyway!

Am I still correct that we will need an updated TSX driver?



Very interesting - my DirectGuide was wiped out on the 5th and after yesterday, my NUC went into meltdown. It would not even respond to a mouse. I am having to reinstall everything from scratch.

I wrote two of my own ASCOM drivers - does anyone know what to be looking out for?

Would these changes to DCOM affect Microsoft Remote Desktop ? That was the other failure mode I had. It would appear to connect and then a blank screen.


The impression I get is that this only affects exe based drivers developed using VB6. This is because these are the only ones that needed a ‘fix’ to the DCOM settings to work with TS6.

If your drivers are DLL based, or use the .NET LocalServer model, they should be OK.

The thing to look for is if there is a section in the installer generator .iss file that looks like this;

; DCOM setup for COM local Server, needed for TheSky
; TODO: If needed set this value to the Telescope CLSID of your driver (mind the leading/extra ‘{’)
#define AppClsid “{{05E24ECE-078E-4973-A772-AE809F525EDB}”

; set the DCOM access control for TheSky on the Telescope interface
Root: HKCR; Subkey: CLSID{#AppClsid}; ValueType: string; ValueName: AppID; ValueData: {#AppClsid}
Root: HKCR; Subkey: AppId{#AppClsid}; ValueType: string; ValueData: ASCOM Celestron Telescope Driver
Root: HKCR; Subkey: AppId{#AppClsid}; ValueType: string; ValueName: AppID; ValueData: {#AppClsid}
Root: HKCR; Subkey: AppId{#AppClsid}; ValueType: dword; ValueName: AuthenticationLevel; ValueData: 1
Root: HKCR; Subkey: AppId\Celestron Driver.exe; ValueType: string; ValueName: AppID; ValueData: {#AppClsid}
Root: HKCR; Subkey: AppId{#AppClsid}; Flags: uninsdeletekey
Root: HKCR; Subkey: AppId\Celestron Driver.exe; Flags: uninsdeletekey

If you don’t have a section like this then your driver should be OK.


thanks - that is a relief - I took your earlier advice and did everything in C#. I’ll check the .iss file to be sure.


This may have also affected the MBox ASCOM observing driver.

I was finishing up a new observatory PC install this weekend and ran into problems similar to above when trying to get the MBox to deliver conditions data to the ASCOM Observing Hub (and thus SGP). Would get some kind of “com” error window when trying to connect.

I tried the “Bob Denny” suggestions above and it now seems to be working fine. Although it is possible that other things I was doing (reboots etc) might have also resolved it.



So here is my user level question:

As far as we have seen at this time, our system was “update affected” in only two ways:

The first was initially the inability of SGP to connect to the “ASCOM Driver for TheSky Controlled Telescopes”. I am not sure why but that seemed to be fixed by reinstalling SGP, the driver, and TSX.

Our big problem was that PhD would could then not communicate with the mount (no response to guide commands). That has been temporarily fixed on our system by backing off the Windows update, but this is only a temporary fix (if I understand it, for about a month).

So here is my question: What needs to be modified by the developer and updated by us before the month is up? TSX, PhD, or “ASCOM Driver for TheSky Controlled Telescopes”?


AIUI Bob Denny’s posts describe what needs to be changed by the user to fix this.

As far as ASCOM drivers are concerned it should also be possible for the developer to fix this by modifying the registry changes that are done by the driver installer. I expect that Bob will come up with some sort of modification to the ASCOM driver install script generator. The driver author could then reissue the driver installer using the appropriate changes. That’s up to the driver author. All that ASCOM can do is provide advice and help.

There may be other related issues. Communication between PhD and SGP for example. This does not use ASCOM so won’t be covered by any changes to ASCOM, it’s up to the various developers to fix this in whatever way is best for them and their users.

BTW if I understand this correctly it will only affect some drivers but not all. In particular it won’t affect DLL based drivers because they run as part of the application process so no additional security is involved. It should also not affect .NET based local server drivers for the same reason. COM is not involved in any inter-process communication with these drivers.