Do not run Astronomy software that uses ASCOM "as Admnistrator".
Running a program "as Administrator" on Windows causes it to run in a separate process space within which the normal protections are blocked. It is like running a program with sudo on Linux, only worse. Windows has rich inter-program communication (which ASCOM COM uses), and Windows prevents programs that are not running "as Administrator" from communicating with elevated/privileged programs that are.
For example, say an app needs to talk to a mount whose ASCOM COM driver is also an executable program (most are nowadays). If that app is running "as Administrator" it will not be able to talk to the mount unless the mount's control program/driver is also running "as Administrator". But wait ... there's more... Now you want to use another app to talk to the mount. Well, now that the mount controller is running "as Administrator", this new app cannot talk to the mount. Now you have to run the new app "as Administrator" to allow it to talk to the mount because the mount is running "as Administrator" so that it can work with the first app which is running "as Administrator"... Do you see the problem?
Fifteen years ago, when Windows Vista came out, and Microsoft introduced an enhanced set of security restrictions for Windows, existing programs often failed due to these new restrictions. This led to a wave of "solutions" where running these programs "as Administrator" bypassed the new security rules, restoring the programs' operation. "Try running it 'as Administrator', that might work."
While this was a useful workaround in the past, today's software should never require being run "as Administrator". To prevent inscrutable techical support issues caused by this, programs are increasingly detecting being run "as Administrator" and prohibiting it.