QAxObject requiring "Run as Administrator"

[jsveiga]

Hello,

Short story: One specific operation with an ActiveX API only works with QAxObject if I run the Qt program "as Administrator" in Windows 7/8. Same ActiveX API works without "Administrator" from an Excel VBA. Am I missing something?

I have been using Qt with QAxObject to use the SAP Business One API integration for years. I'm currently using Qt 5.2.

Unfortunately after a SAP B1 upgrade last year I started getting an error when establishing a database connection (I could workaround it, and the QAxObject still works with the API; it's just the initial connection that I had to workaround by "capturing" the session from an open SAP login UI).

At first I thought it was only an API problem (and could not complain to SAP, as Qt integration is not officially supported), but recently I realize that if I run the Qt program "as Administrator", the connection works fine.

It is not the ActiveX API that is requiring administrator, because I can use the same objects from an Excel VBA without running it "as Administrator".

Is there some "trusted" list of applications which can use an ActiveX object without Admin? Any hints?

Here's my old post at the SAP forum with more details (note that I only found out about UAC recently, so the first posts are guessings):
https://scn.sap.com/thread/3568698

Thanks!

Joao S Veiga

[ChrisW67]

Perhaps the third-party ActiveX object is writing to the process current working directory and failing because it is under "Program Files" or "Windows". Excel's working directory may well be writable and your app's not.

Try manually launching your program from a command prompt that has a writeable directory as its cuurent directory (or use the app desktop icon to achieve the same)

[jsveiga]

Perhaps the third-party ActiveX object is writing to the process current working directory and failing because it is under "Program Files" or "Windows". Excel's working directory may well be writable and your app's not.

Try manually launching your program from a command prompt that has a writeable directory as its cuurent directory (or use the app desktop icon to achieve the same)

Thank you for your suggestion. That makes sense, but unfortunately it's not it :-(

I tried running both from Qt SDK (then the working dir is the build dir) and from a directory containing the Qt dlls. In both cases I have write permissions to the directory, but still no luck. If I right-click and "run as administrator", or create a shortcut and set compatibility mode for XP (which triggers the UAC dialog), then it works. (I just redid these tests to make sure).

Thanks again!

[Rondog]

I have had some problems with IDispatch and Automation (related to QAxObjects) in the past. Some things I can suggest:

- Check the Windows event viewer. You might see messages in the failed attempts recorded in the logs. That may be useful if you do.

- Check the security settings specific for the application you are trying to connect to. This is in the Windows Administrative tools under Component Services. You will see a list of applications and one is likely the one you are trying to connect to. It could simply be blocked if you do not have permission to access the software. It is something like Component Services - Computers - DCOM (?).

I assume Excel can handle almost any situation (and since they know all the tricks I wouldn't presume anything based on what they can or cannot do).

In my case I had problems where I could not access a particular program using Automation (IDispatch) unless I was running is administrator (sounds exactly like your situation). When I checked the component services I noticed that this specific application security settings would not allow regular uses to access it for some reason. These settings can be customized for specific applications.

The application might be part of the problem to. I suspect a more complete application would permit user access (specific access) from an elevated privilege program but who knows.

[jsveiga]

Thank you Rondog,


I have had some problems with IDispatch and Automation (related to QAxObjects) in the past. Some things I can suggest:

- Check the Windows event viewer. You might see messages in the failed attempts recorded in the logs. That may be useful if you do.



I checked the event viewer, both before/after running the app as admin/normal user. No new events were logged :-(




- Check the security settings specific for the application you are trying to connect to. This is in the Windows Administrative tools under Component Services. You will see a list of applications and one is likely the one you are trying to connect to. It could simply be blocked if you do not have permission to access the software. It is something like Component Services - Computers - DCOM (?).




I had never seen these settings, thanks. I went there, and although I found SAPbouiCOM (the UI API for SAP B1), I could not find the DI API (SAPbobsCOM), which is the one I use and is failing on connect (one workaround I use it to use the UI API to "capture" a logged session then use it in the DI API, but it requires that the user is logged on to SAP).

In any case, I opened all the permission I could find for SAPbouiCOM (full control for everyone, all application packages, users), but still no luck.





I assume Excel can handle almost any situation (and since they know all the tricks I wouldn't presume anything based on what they can or cannot do).

In my case I had problems where I could not access a particular program using Automation (IDispatch) unless I was running is administrator (sounds exactly like your situation). When I checked the component services I noticed that this specific application security settings would not allow regular uses to access it for some reason. These settings can be customized for specific applications.

The application might be part of the problem to. I suspect a more complete application would permit user access (specific access) from an elevated privilege program but who knows.

How I wish there was a decent strace equivalent... (tried dr. memory drstrace, but it only shows the calls, not the returns).

I have two workarounds for now: One, as I mentioned, uses the UserInterface API to capture a connected session (but requires that the user is logged on to SAP B1), the other is that I created a "helper" app in Qt with a "require admin" manifest, and I call that from the main Qt app for specific operations - but of course this triggers the UAC dialog, then only users with Administrative rights can use it.

I also tried to enable debug logging on the SAP API itself, but when it fails it logs nothing (it seems it only logs after the connection is succeeded).

So the mistery goes on...

Thank you again,

Joao

[Rondog]

If nothing is logged or appears in the event viewer is then likely the problem is not "The requested operation requires elevation" type of problem. These usually are logged.

If you didn't see the application in the component services it could be a 32-64 bit related problem. If you are running a 64 bit version of windows and this application is 32 bit you won't see it listed (you will only see the 64 bit applications). To open the 32 bit version of the component services run the command 'MMC COMPEXP.MSC /32' from Start-Run or from a command prompt.

[jsveiga]

If nothing is logged or appears in the event viewer is then likely the problem is not "The requested operation requires elevation" type of problem. These usually are logged.

If you didn't see the application in the component services it could be a 32-64 bit related problem. If you are running a 64 bit version of windows and this application is 32 bit you won't see it listed (you will only see the 64 bit applications). To open the 32 bit version of the component services run the command 'MMC COMPEXP.MSC /32' from Start-Run or from a command prompt.

Thank you again; I tried that (it's COMEXP.MSC), but again, only the UI (SAPbouiCOM) appears there. The APIs are indeed 32 bits.

Sill puzzled...

[Rondog]

I read through the other post you mentioned in this thread. It covers things I try to avoid (namely MS SQL - bleh!).

The odds are that you do have a permission problem somewhere. Having it work when running as administrator suggest this is true and also suggests your approach is valid. For MS-SQL the user credentials could be an issue (running as 'admin' might make it think you are someone else?) so it doesn't necessarily guarantee that it is a permission problem (it might be a problem from the database server and not from COM based on your user name).

I didn't see any method in QAxObject to get the last error. When you run 'dynamicCall("Connect")' if it is failing here an error message might be helpful information. I wrote my own small class to handle IUnknown / IDispatch many years ago (before QAxObject) so I have not used QAxObject at all yet (I was planning to start using it some day when I needed features that my stuff didn't have). These error messages are helpful for solving these kinds of problems and it seems to be something that is missing from QAxObject (?).

If it is a database connection problem maybe you can turn on the trace option for the database. I did this for a problem I was looking at a few years ago (I don't remember exactly how I enabled this feature). It gave me some very detailed information about what was passing back and fouth between the computer and the database and it did help identify a problem. Maybe something along these lines would be helpful. The problem only started after an upgrade (as suggested in the post you linked to) so maybe there is some sort of protocol change?

You could write up something in C/C++ using the Win32 API directly for IUnknown / IDispatch to run some tests with. Microsoft has samples of this on their website you could use as a reference. This would at least eliminate a few variables and possibly provide you with some more information related to the source of the problem. It is ugly stuff but interesting never the less.

[jsveiga]

Thank you again and again...


I read through the other post you mentioned in this thread. It covers things I try to avoid (namely MS SQL - bleh!).

The odds are that you do have a permission problem somewhere. Having it work when running as administrator suggest this is true and also suggests your approach is valid. For MS-SQL the user credentials could be an issue (running as 'admin' might make it think you are someone else?) so it doesn't necessarily guarantee that it is a permission problem (it might be a problem from the database server and not from COM based on your user name).


The database connection information is passed to the SAP BusinessOne API (the "company" object), then it uses it when "connect" is called. What puzzles me is that the exact same parameters are passed to the API when calling from an Excel VBA, and it works without admin. And in Qt it fails even if I pass the MS SQL sa (admin) user and password.

(I use MySQL for "my" side of the integration; SAP didn't give the option...)


I didn't see any method in QAxObject to get the last error. When you run 'dynamicCall("Connect")' if it is failing here an error message might be helpful information.


Sorry, right after the "Connect", I call the dynamicCall("GetLastErrorDescription()").toString() on the company object, and it returns "Database server type not supported", which is a bogus message; the database type "6" which is passed is for MSSQL2008, and works "as admin" and with Excel.
It seems like when called by Qt "non-admin" the API object cannot connect to the DB, and throws this bogus message.



If it is a database connection problem maybe you can turn on the trace option for the database. I did this for a problem I was looking at a few years ago (I don't remember exactly how I enabled this feature). It gave me some very detailed information about what was passing back and fouth between the computer and the database and it did help identify a problem. Maybe something along these lines would be helpful. The problem only started after an upgrade (as suggested in the post you linked to) so maybe there is some sort of protocol change?


Tracing is a good idea; I'll check if I can set it up (I've used it before with DSNs, but in this case the API uses the SQL Native client directly). Yes, it started after an upgrade; I was convinced it was something which made it incompatible (such as protocol), but then it works as admin!



You could write up something in C/C++ using the Win32 API directly for IUnknown / IDispatch to run some tests with. Microsoft has samples of this on their website you could use as a reference. This would at least eliminate a few variables and possibly provide you with some more information related to the source of the problem. It is ugly stuff but interesting never the less.

I'll see if I can find out how to do this!

thanks again, and best regards,

Joao

[jsveiga]

I tried to enable trace with

https://technet.microsoft.com/en-us/library/cc765421%28v=sql.100%29.aspx

But I guess I didn't manage to, because the trace shows almost nothing, and it is identical when I run the program as admin (connection succeeds) or normal user (connection fails).

Damn it's hard to trace problems in windows! A simple "strace" on linux could provide a lot of information!