What Options Do I Have with Access Denied Errors...
Hi All,
We have sort of strange situation when a user attempts to install our software. They've tried on 5 machines and received the following error on all...
I'm not quite familiar with this but I've been told the user uses Office E5 - an advanced Windows Defender Anti-virus. If the anti-virus is turned or an exception for the user temp directory (C:\Users\<someuser>\AppData\Local\temp) is added in Windows Security, the install works fine.
In the exceptions, there is also a file exception for our .msi, but that didn't solve the problem on its own. It's only when the directory exception is added that things proceed as expected.
The only issue is their IT department will not allow that exception. Why, I'm not sure.
They also provided this...
So, I thought things cannot be extracted due to permissions/restrictions. The log however tells a different story. There is an action, which runs in the same context as a later action that is failing, but that completes successfully.
Here's the log of action success...
MSI (c) (14:58) [15:18:33:396]: Doing action: VCRuntimeCheck
Action 15:18:33: VCRuntimeCheck.
Action start 15:18:33: VCRuntimeCheck.
MSI (c) (14:1C) [15:18:33:397]: Invoking remote custom action. DLL: C:\Users\My.User\AppData\Local\Temp\MSI10ED.tmp, Entrypoint: VisualCPPDetect
SFXCA: Extracting custom action to temporary directory: C:\Users\My.User\AppData\Local\Temp\MSI10ED.tmp-\
SFXCA: Binding to CLR version v4.0.30319
Calling custom action VisualC++Detect!VisualC__Detect.CustomActions.VisualCPPDetect
Begin required Visual C++ detection...
Action ended 15:18:33: VCRuntimeCheck. Return value 1.
Here's the action that fails afterwards...
Action 15:18:33: InventorIntegrationCheck64.
Action start 15:18:33: InventorIntegrationCheck64.
MSI (c) (14:48) [15:18:33:586]: Invoking remote custom action. DLL: C:\Users\My.User\AppData\Local\Temp\MSI11AA.tmp, Entrypoint: FindInventor
MSI (c) (14:C8) [15:18:33:586]: Cloaking enabled.
MSI (c) (14:C8) [15:18:33:586]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (14:C8) [15:18:33:586]: Connected to service for CA interface.
CustomAction InventorIntegrationCheck64 returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 15:19:08: InventorIntegrationCheck64. Return value 3.
This is logged immediately after this...
MSI (c) (14:58) [15:19:08:040]: Doing action: SetupCompleteError
Action 15:19:08: SetupCompleteError.
Action start 15:19:08: SetupCompleteError.
Info 2898.For Tahoma8 textstyle, the system created a 'Tahoma' font, in 1 character set.
Info 2898.For TahomaBold10 textstyle, the system created a 'Tahoma' font, in 1 character set.
Action 15:19:08: SetupCompleteError. Dialog created
MSI (c) (14:90) [15:19:08:063]: Note: 1: 2731 2: 0
MSI (c) (14:A4) [15:19:14:531]: PROPERTY CHANGE: Adding ISSHOWMSILOG property. Its value is '1'.
MSI (c) (14:A4) [15:19:15:511]: Doing action: ShowMsiLog
Action 15:19:15: ShowMsiLog.
Action start 15:19:15: ShowMsiLog.
MSI (c) (14:A4) [15:19:15:511]: Note: 1: 2732 2: 0
Error 2732.Directory Manager not initialized.
MSI (c) (14:A4) [15:19:17:665]: Product: MyCompany MyApp Client -- Error 2732.Directory Manager not initialized.
Action ended 15:19:17: ShowMsiLog. Return value 3.
So, I'm not sure if this is expected behavior. I'm not sure why one action fails and the other does not.
I don't know if its possible to direct the temp directory files/operations to another location from the command line, but I doubt it (can't pass TempFolder as its not a PUBLIC PROPERTY)).
Is there anything I can look at to troubleshoot?
Answers (1)
The first thing I'd be doing is finding out, using ProcMon, what happens when the FindInventor function is called from the extracted DLL.
TBH, though, it can only realistically be doing one of two things: finding a file or finding a registry entry. Once you have that information, you can build your own detection and add it to your transform. Then, also in your transform, condition-out the offending CA InventorIntegrationCheck64 - I usually just add the condtion '0=1'.
The directory manager error is normally due to a CA being run before any of the costing Standard Actions. Check the sequence numbering in the relevant tables. Alternatively, just add ISSHOWMSILOG=0 to your transform or command line - it's of no interest to the user!
Comments:
-
Hi VBScab,
Long time no forum conversations.
Here's what the action does, just checks a reg key and sets properties based on what it finds...
rKey = Registry.LocalMachine.OpenSubKey("Software\Autodesk\Inventor\RegistryVersion22.0")
If Not rKey Is Nothing Then
rKey.Close()
session.Item("INVENTOR2018") = "1"
session.Log("Supported Inventor Version (2018 x64) Found.")
Else
session.Item("INVENTOR2018") = "0"
session.Log("Inventor 2018 NOT Found.")
End If
Return ActionResult.Success
Since this user will not be using that product, I simply conditioned the action not to run (condition set to 0).
The action that succeeded previous to this does basically the same thing but is a little more robust. It checks for installed versions of the Visual C++ runtimes and compares to version a version constant (our required version) and sets properties based on that and writes to the session log.
I'm puzzled as to why that action is failing. - Superfreak3 3 years ago-
>I'm puzzled as to why that action is failing
Is 'ActionResult.Success' defined and populated elsewhere?
On a related note, it seems to me, looking at the code, that the action will *never* return a failure: I'd move "Return ActionResult.Success" to just before the final 'End If'
What does ProcMon tell you when the CA executes?
Lastly, please use the 'CODE' style for code :-) - anonymous_9363 3 years ago-
I don't think the placement of ActionResult really matters in this case. It just needs to determine if there is a registry key present or not. The only think of consequence is opening the key. If that Either way, ActionResult will be reached in this code. It's never been a problem before.
The only thing of real concern would be the opening of the reg key. If that fails, the action would fail, no?
We never got to try procmon as the customer needed to move forward. So, conditioning the action to not run was sufficient for them.
It was just odd and I really wish we could have gotten to the bottom of it. That action has been in the install for years without failure anywhere.
At any rate, this is the last release which will contain that action, which is why I'm not too concerned I guess. We won't be supporting any Inventor versions in this package in the next release.
Sorry about the code format!
Just heard back from the customer and they're receiving a similar problem with a similar action in a different install package. Only in this case, the action cannot be turned off as it's needed.
I am totally stumped. I think I mentioned that a similar running under the same context succeeds immediately before the failing action.
The first part of the code is simply a write to the install log and it's not even getting into the code it seems.
They are using Microsoft Defender ATP, which is flagging the install. - Superfreak3 3 years ago
