OK, so in our specific case, first Bob would need to modify the ASCOM driver installer and then the author of the “ASCOM Driver for TheSky Controlled Telescopes” would need to reissue the driver?
Also, my imaging partner on that remote system did try Bob’s fix for our issue yesterday and it did not work. I was not available so do not know exactly what he did but he was following Bob’s online instructions and has software experience so should have gotten it right.
@CCDMan Check the posts on the DC-3 Dreams Comm Center, specifically this one.
@Chris There are multiple issues here and things to consider before making changes to the development tools. I will be talking to Peter, then we I will make a post for developers on the ASCOM Talk forum topic for this issue, as well as needed info on the ASCOM web site Developer’s section.
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.
Correct.
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.
This isn’t right on two accounts.
The DCOM info is almost certainly present in the .NET local servers. It is added in the boiler plate code that virtually everyone uses to make local server ASCOM drivers. It is also present in all of the simulators that come with the ASCOM Platform.
COM is indeed used for inter-process communication between a .NET local server driver and any client, whether it is .NET, VB6, Script. C++ or whatever else. The only other IPC mechanism in .NET is the ancient and awful “.NET Remoting” and we definitely do not use that for IPC. COM rules because it is language independent.
OK, so in our specific case, first Bob would need to modify the ASCOM driver installer and then the author of the “ASCOM Driver for TheSky Controlled Telescopes” would need to reissue the driver?
Not necessarily me, as ASCOM is open source. But I will probably make the changes into the tree and coordinate when this gets pushed out to a new Platform. Keep in mind this will affect only drivers written in the future. All current drivers with DCOM info need to be changed and re-released. This will be the responsibility of the driver developers not the ASCOM Initiative (or me!). The ASCOM 2X Mount Adaptor for TheSky X comes from Software Bisque.
Please note, though, that any driver developer will shortly be able to see what needs to be changed in existing drivers and their existing driver installers. They will need to go to the ASCOM Talk forum not here.
Why do we need DCOM info?
Again this was needed (and may still be needed!!) for TheSky 6. It is possible that someone has used DCOM to distribute drivers and clients for ASCOM, and we cannot remove this without the risk of breaking these applications (TheSky 6 included). So we need to fix the Authentication Level to be the newly required value for Windows 10 (=3).
Also, my imaging partner on that remote system did try Bob’s fix for our issue yesterday and it did not work.
If this is an ACP or ACP Expert customer of course I will help. Post on our Comm Center.
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.
I need to defend the honor of the ASCOM driver authors out there, to include (alphabetically) Astro-Physics, Optec, PlaneWave, Software Bisque, and others. The drivers are not “improperly written”. Neither the driver authors who used the ASCOM templates and installer generator, nor the author of the templates and installer generator (me) could have foreseen ten years ago (yes! 2007!) that Microsoft would change the DCOM security requirements on components *that are not even using DCOM. Let’s give these guys a break. Your friend is on the rifght track, but I can’t imagine that he knew this was a “known flaw”. Furthermore, in the release notes for KB4075892, Microsoft states that the change is a “known issue” and that “Microsoft is working on a resolution and will provide an update in an upcoming release.” So its unclear that this is a “known security flaw in COM”.
I hope this will give everyone here enough info to keep new “Uncle Festus” speculation, finger pointing, blame, frustration, etc. from getting even worse. I’ve done my best to bring objective engineering analysis and reporting on this.
For more info please see the ASCOM-Talk topic and our ongoing thread on the DC-3 Dreams Comm Center.
My imaging buddy, who is an EE and software savy, did that and it did not work. Rolling back the update did work but is temporary
The Bisques seem to be saying that this is one of the issues, yes. From my point of view, as a user, all I need to know is what software and/or drivers need to be fixed/updated. I am not trying to assign blame, I (we) just want something that works and will continue to work for the foreseeable (note that word with regard to this issue) future.
@CCDMan who are you? What “did not work”? What does that mean? Was this a connect from SGP to TheSky or ??? I’m on the lookout for exceptions but so far the above info isn’t enough for me to go on.
What I’ve found is that the Local server based Celestron driver seems fine, even without the DCOM fix.
I thought there was a problem with the NiteCrawler focuser because I was getting a timeout error but it seems to have healed. I’m not sure if the fix is needed, I tried it and it made no difference but then the communication worked and removing the fix made no difference. I would have expected some sort of security error, not a timeout.
The MoonLite DRO driver is also OK. That’s also a LocalServer based driver.
The ones that need to be fixed are the ones that stopped working with the update. There is no “master list” … heck this problem only appeared three days ago. To get something that works and will continue to work, make the change using DCOMCNFG to the devices that are giving you trouble If it doesn’t work I need to know more and maybe I can figure out why it doesn’t work. Ideally I’d get a chance to test the same configuration.
OK, to take those in order:
Who am I best explained on my webpage (and is also in my profile on this forum): Nightskypictures
Also involved is Tom Carrico, my partner at Deep Sky West remote site.
What did not work was the ability to guide our Paramount ME from PhD. PhD logs indicated that “debug log file shows the TSX ASCOM driver is returning an immediate result of “not guiding” after each guide pulse is sent.”.
What also did not work was modifying according to Bob’s instructions shown at: Bob Fix. I cannot comment on how this was performed as Tom did that and said it did not fix the guide issue. He is pretty savvy so I would be surprised if he got it wrong.
What did work was rolling back the update but, as has been stated elsewhere, this is only a temporary fix.
I think that the above answers all the questions.
Let me know if any other information is required.
Thanks!
@CCDMan OK, thanks. I thought you were someone else. I remember you from a few years ago. I can’t repro your situation as I don’t have a way to test PHD here with TheSky. All I can say is that once TheSky’s Auth level was changed to Call I can talk to it from POTH, ACP, and MaxIm. Note that, in DCOMCNFG, there are two entries “TheSkyX” and “TheSkyXAdaptor” and I am unsure which one is the real one. I would change them both as that would be harmless. No one uses DCOM anyway. If there is a DCOMCNFG entry for PHD, you should change it too. And make sure you look with the 32-bit DCOMCNFG if you don’t see someting listed in the (default) 64-bit one. Changing Auth level in the 64-bit one changes the 32-bit auth level too. See the revised post on the Comm Center towards the botton on how to run the 32-bit DCOMCNFG. This is a one-time fix (well unless you install a driver update which doesn’t have this issue fixed).
OK, thanks!
I will get that information to Tom as well.
I lied about POTH. I forgot that I had to change its Authentication level as well. You need to use the 32-bit DCOMCNFG and look for ASCOM Focuser Driver for POTH. I’m getting a weird LST error of 1441 sec. However the coordinates show correct (RA/Dec/Alt/Az) and slews follow etc.
Don’t use POTH myself although I am acquainted with Jon who wrote it - he is a good friend and former HP associate of Tom’s.
Getting deeper. Though I can connect to TheSky from ACP and now POTH and MaxIm, it is refusing to supply latitude/longitude coordinates, and the LST is off (possibly 0) and its not supplying alt/az. This is boiling down to TheSky still being troublesome. This is also preventing FocusMax from completing a connection (cannot get coordinates). Strange because some of the functionality is OK (slewing, reporting ra/dec coordinates). This goes along with your not being able to get TheSKy to accept PulseGuide from PHD. I may be out of my area on this one as I don’t know what goes on in the Bisque driver or TheSky. Maybe there’s a secret COM connection we can’t identify or ??
I know Jon well. I’ve been to his house 
Something to add, before I was aware of the wider picture, I decided to re-install Windows 10. I have a simple VirtualCom Port serial on a relay - it now refuses to work - thought it might be my ASCOM driver but I used the company’s own tester - worked fine with Win 7 from my laptop, through all my powered hub network, but when I substitued for my NUC running Win 10 I can see that no commands are getting through (RX/TX leds). The COM port settings are identical, with the same driver etc and says it is working. The NUC is working fine through the same USB port with all the other devices, including 5 other FTDi COM ports. Really odd. Feel like going back to Win 7.
Interesting your comment about not getting lat/long from the mount. That was also noted in our PhD logs.
As far as making Bob D’s fix, I was very careful about working through the DCOM list and making the changes. I saw the 2 SKYX entires and also worked through the 32 bit version of the list. Then I checked it twice. After doing all that, re-starting the computer and all the software PhD 2 would still not guide. Everything else worked fine. It was only when I rolled back the update that PhD 2 started guiding again. I could have missed something, but it would have to have had a really bizarre non astronomically related name.
Forgot that my moniker is SMJT 7331. I am Tom Carrico, Bill’s imaging buddy.
During the eclipse? I know he built it there partly because it was under the path! In fact, both Tom and I lived under the path as well, albeit 200 miles apart. What are the odds?
Interesting on the Pulseguide and TSX. I posted this issue on the SB site and it does not sound like they plan on changing anything, rather plan to wait for MS to issue an update that fixes things. Hope they do.
Just deferred the update on my home roll-off. Fortunately that PC has been powered down due to our cloudy weather.
I posted earlier on the SB site - if I’m seeing the same issue, when PHD2 failed to do DirectGuide, I found that TSX itself wouldn’t either and reverted to ST4
OK, I’ve gathered some more detail on TheSky X post-patch. Some other stuff is going on inside that appears to be unrelated to the connection/DCOM problems. I can connect OK, and I didn’t notice some of this stuff till I tried to connect from FocusMax and it failed for not being able to get lat/long/elev. Then I tried to do some stuff after connecting from MaxIm’s Observatory Control. Something weird is going on with tracking control. I have posted the info and a pipe log to the SB forum in this post:
http://www.bisque.com/sc/forums/p/32569/167028.aspx#167028
As it is, it appears that TheSky X (10.5.0 b11117 dbi) ASCOM telescope control can’t be used with the January 2018 Security Rollup patch applied. Other than that, TheSky X appears to be working fine.
First clear night in a while …
I’ve now discovered that the AstroMC (Foster Systems dome control) driver was also affected by this Windows 10 update. Following Bob Denny’s “fix” did the trick, so up and running again.
I note that PHD2 has not been a problem for me with this Windows 10 update. But I don’t use TheSky or Paramount mount (using EQ8 with EQMOD, PHD2 latest beta and ST4 guiding).
DaveNL