Results 1 to 6 of 6

Hybrid View

  1. #1
    Join Date
    Oct 2005
    Mesa, AZ

    Default ALERT: Windows 8.1 and 10 Updates KB4056898 and KB4056892 Reported Problems

    Microsoft has released Windows 10 Update KB4056892 (OS Build 16299.192) which may be in response to the recently discovered CPU vulnerabilities as described in this article: Meltdown and Spectre CPU Vulnerabilities: What You Need to Know. We have received some reports of this update possibly causing ACP and other client programs to fail when trying to connect to some ASCOM-compatible devices including TheSky X acting as a telescope controller.

    If you want to see or participate in the discussion here, you will need to have current Support and Upgrades, as the discussion is running in the premium ACP Observatory Control support section:

    Windows Update KB4056892 - Possible Problems With ASCOM Connections

    At this point we don't have any solid evidence or cause-effect information. The update just came out a couple of days ago (04-Jan-2018). We posted this alert to let you know that we are aware of possible issues. It is possible, based on reading some of today's news traffic, that this was a rushed-out update with some known problems (see the KB article linked above).
    Last edited by Bob Denny; Jan 6, 2018 at 19:32. Reason: Updates progressing again
    -- Bob

  2. #2
    Join Date
    Oct 2005
    Mesa, AZ


    I have confirmed this to be a general problem introduced by KB4056892 (and we now know that KB4056898 for Windows 8.1 has the same security change)! I started with a clean Windows 10 system with only ASCOM Platform 6.3. I tested POTH connecting to the ASCOM Telescope Simulator for .NET and the old ASCOM Telescope Simulator (VB6 Based). No problems. Then I manually installed KB4056892. After that here are the results:

    Name:  Snap1.jpg
Views: 606
Size:  155.9 KB

    Name:  Snap2.jpg
Views: 300
Size:  148.9 KB

    Rowland Archer nailed it in the ACP Forum discussion thread by posting the "known issue"

    Name:  Snap3.jpg
Views: 299
Size:  68.0 KB

    This is it. See the next post for how to solve it.
    Last edited by Bob Denny; Jan 12, 2018 at 21:12. Reason: Add info for Windows 8.1 KB4056898
    -- Bob

  3. #3
    Join Date
    Oct 2005
    Mesa, AZ


    UPDATE 17-Jan-2018: The ASCOM Initiative has provided a tool for making the security change to EXE drivers, elimininating the need to do the procedure below for EXE ASCOM drivers. You may still need to make this change to programs that have Programming Interfaces used by other programs, so we're leaving the manual instructions below. The tool is located at

    To use it:

    1. Create a new directory on your PC
    2. Extract the three files in the zip into the new folder
    3. Double-click the FixDCOM executable (you may need to answer yes run after downloading)
    4. Answer Yes to the "Do you wish to allow changes?" security dialog
    5. Select the "Apply revised settings..." from the dropdown list
    6. Click Apply

    Name:  Snap6.jpg
Views: 2478
Size:  7.9 KB
    MANUAL WORKAROUND: As the Microsoft supplied workaround in the previous post says, the components need to have their call level changed to "Call". Thank goodness, this can be done using the DCOMCNFG tool, an MMC snap in. The tricky part is going to be identifying the various ASCOM and application servers you need to adjust!! Read all the way to the end or you'll miss important and useful stuff.

    Don't do anything unless you actually have a problem.
    Note that neither ASCOM nor its client apps use Distributed COM (DCOM). The names are historical only.

    1. Type DCOMCNFG into the Windows Search box (lower left corner of your screen). You may have to wait a while while it installs the Component Services snap-in the first time you do this. Be patient.

    2. Eventually you should see the Component Services window. Expand the tree to see DCOM Config

    Name:  Snap4.jpg
Views: 2506
Size:  50.6 KB

    3. Now for the tricky part. Under the DCOM Config "folder" is a long list of components, most of which belong to Windows itself and to the many apps that make use of this Windows feature (COM). Your task is to locate those which you need for your astronomy uses. This will include drivers for devices and anything that may be used by another app. POTH is an example, it is used by other programs because it looks like a telescope, dome, and focuser to its clients. If in doubt just change its authentication level, it's harmless. Use the ASCOM Profile Explorer to find the System name for the devices you see in the Chooser. Then find it by system name in DCOMCNFG. Here is the entry for the "Telescope Simulator for .NET" in the ASCOM Profile Explorer

    Name:  Snap7.jpg
Views: 2509
Size:  90.0 KB

    Note that it's system name is ASCOM.Simulator.Telescope.

    4. Now find this in DCOMCNFG's list of components. Right click, Properties, then change None to Call in Authentication Level. Then click OK:

    Name:  Snap5.jpg
Views: 2508
Size:  151.4 KB

    5. If you don't find your problematic component in Step 4, then run a 32-bit DCOMCNFG.
    5a. Open a CMD shell enter CMD into the search box)
    5b. Type C:\WINDOWS\SYSWOW64\mmc comexp.msc /32
    5c. Now look in this DCOMCNFG for your troublesome component (MaxIm DL will appear only here for example!)

    Continue finding things in the ASCOM Profile Explorer and the 64-bit and 32-bit DCOMCONFG, setting the Authentication level to Call. If you encounter a non-ASCOM component that stopped working after KB4075892, and you know it has a scripting or programming API then find it in DCOMCNFG and change its Authentication Level to Call as well. This includes ACP itself which is listed ACP Observatory Control Software.

    * For Software Bisque TheSky X look for TheSkyX and TheSkyXAdaptor and change both to Call
    * For MaxIm DL you must look in the 32-bit DCOMCNFG and you'll find it as MaxIm.CCDCamera
    Last edited by Bob Denny; Yesterday at 18:07. Reason: Add 32-bit DCOMCNFG info as well as MaxIm and TheSky identifiers
    -- Bob

  4. #4
    Join Date
    Oct 2005
    Mesa, AZ


    * This all relates to Windows 10 only, not Windows 7/8/8.1
    * This affects inbound connections to EXE based drivers and programs with APIs. DLL based drivers are not affected.
    * If you have not yet updated your Windows 10 to the Fall Creators Update v1709 but are still on the old Windows 10 v1703, you will get this patch as a slightly different KB number. It's still the January 2018 Security rollup. But you may not have any trouble at all. Therefore ...
    * There are several workarounds circulating that include uninstalling the KB4057892. It will just get installed again. Then there is one that recommends using a tool to hide the patch from Windows. Not a good idea as this one may be a prerequisite to future patches and you'll end up not getting those or they may fail. Then you could have a mess. Another one suggests using the Windows Update settings to Pause updates, which will stop patches for a month or so, then uninstalling this KB patch. These just prolong the inevitable. By doing the DCOMCNFG changes you are making a permanent workaround that is harmless for future usage.


    We had one gent report that he could not find the EQMOD listed in DCOMCNFG. While analyzing this further today (see below) we found that there is a 32-bit DCOMCNFG which will see 32-bit-only components. We have updated the workaround post on our Comm Center with additional instructions for getting the 32-bit DCOMCNFG running. In short:

    1. Open a CMD shell (cmd.exe)
    2. Enter the command C:\WINDOWS\SYSWOW64\mmc comexp.msc /32

    You will see a DCOMCNFG open that looks just like the original one, but may contain a listing for your troublesome component.

    MaxIm DL is listed in the 32-bit one only as MaxIm.CCDCamera. FYI TheSky X is listed twice, as TheSkyX and TheSkyXAdaptor, and these show in the 64-bit one. Changing in the 64-bit one makes the changes to both 64- and 32-bit info.


    Today we analyzed this issue further and have found that it is related to the DCOM permissions which were added to ASCOM components 10 years ago in order to make them compatible with TheSky 6, which uses DCOM for the old SB Internet Astronomy Suite. Those LocalServer components which do not have DCOM compatibility info registered with them will accept inbound connections with no problems. This is why some things work and some don't. Unfortunately, the Installer Generator tool for ASCOM driver developers has this DCOM stuff baked in. Rather than risk compatibility problems with TheSky 6 (and yes there are still people using it), the right way to fix this is to change the DCOM authentication level as described in our article, and doing this within the Installer Generator.
    Last edited by Bob Denny; Jan 10, 2018 at 17:05. Reason: Note about EXE only
    -- Bob

  5. #5
    Join Date
    Oct 2005
    Mesa, AZ


    UPDATE ON THESKY -- After some testing today, I've found that TheSky's ASCOM Telescope Control is still not working right, even though there is no longer a problem connecting for ASCOM. So the DCOM changes work to allow access. However several other things aren't working such as getting lat/long/elev, sidereal time is always 0h, tracking is always off and is reported to be stuck off. I have reported this along with a Pipe trace.
    Last edited by Bob Denny; Jan 10, 2018 at 17:08.
    -- Bob

  6. #6
    Join Date
    Oct 2005
    Mesa, AZ


    HISTORICAL INFO: I posted this on the ASCOM group this morning, and it came out pretty good. So (with a few edits) I'm reporting it here as historical info.

    As I noted in the previous post TheSky has its own problems with KB4056898, apparently unrelated to the DCOM Auth change. For all other drivers and API-bearing apps, the DCOM Auth adjustment is enough to get going. Also, note that this Windows security change should have only affected the very few Microsoft customers that are actually using DCOM, and no ASCOM drivers or API-publishing astronomy apps use DCOM. However...

    The reason it DID affect these astronomy drivers and apps is that many years ago (10+ years) Software Bisque DID use DCOM, for its Internet Astronomy Client/Server Software (IAS). So TheSky 5/6 registers itself for DCOM with the Windows OS. Back then, in order to provide TheSky 5/6 with the ability to control ASCOM-compliant mounts, the ASCOM Initiative provided a TeleAPI plugin for TheSky that translated the Software Bisque TeleAPI calls into ASCOM. This opened up TheSky's compatibility beyond its built-in telescope control logic to ASCOM. It was quickly discovered that EXE based ASCOM drivers (only) were inaccessible from TheSky/TeleAPI due to DCOM access restrictions coming from TheSky 6. So the drivers, the ASCOM templates, and the installer tools were enhanced to provide DCOM Authentication info as part of the drivers' registration, with the Authentication level set to "None". This was found to be the correct level per Microsoft for connections between EXE processes on the same machine running under the same user. This is the case for ASCOM usage, so for 12+ years, this was fine.

    Fast forward to Jan 2018 ... Microsoft changed the requirements for DCOM (which almost no one uses) between processes on the same system under the same user from "None" to "Call". Was it a mistake? Could they have ever caught it in regression testing? Software Bisque CERTAINLY could never have guessed this would happen, nor could the ASCOM people who added in the DCOM Authentication. It is a "perfect storm" of events that got us here.

    Will Microsoft "fix" this? It's unclear whether it was an accident or intentional. They publicly say it's a "known issue" and that it will be "resolved" in an upcoming release. Knowing all of the above, I would not classify this as Microsoft's "fault". Again, the reason we can't pulse guide (or even slew through its ASCOM interface) with TheSky X is not related to the DCOM issue, but something else with TheSky X that the KB4056898 triggered. I do not know if it's Microsoft's fault or if there was a latent weakness in TheSky that was triggered by the update.

    No one deserves any "blame" in any case. Everyone is doing their best. I will say this: Microsoft has maintained compatibility for applications over the years far better than Apple or the hordes of Linux flavors out there. Of course ancient hardware becomes obsolete and unsupported.
    -- Bob



Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Similar Threads

  1. Windows 10 updates causing issues with ACP
    By Dean Salman in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 12
    Last Post: Jan 8, 2018, 04:32
  2. Windows 10 uninstall reinstall problems - a fix from Microsoft
    By Colin Haig in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 1
    Last Post: Jan 3, 2017, 22:41
  3. Mount failed to flip based on its reported pier side info. Wrong Alt/Az reported pos
    By Steve Reilly in forum Hardware/Software/Driver Topics Not Directly Related to Our Software
    Replies: 5
    Last Post: Jun 28, 2012, 02:18

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts