Occasional contributor

Access to the Temp Directory Denied...

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...

Annotation 2020-05-06 195010.png

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?  

Labels (2)
0 Kudos
7 Replies
Occasional contributor

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

session.Item("INVENTOR2018") = "1"
session.Log("Supported Inventor Version (2018 x64) Found.")
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.

0 Kudos
Frequent contributor

Just 2 questions:

  • have you signed the MSI package and also all your support/program files ?
  • it looks like you use VBScript in your MSI package, is this correct ?



0 Kudos
Occasional contributor

Yes, everything is signed when the package is created.

I don't believe there is any vbscript left in the pacakge.  There may be a Visual Basic custom action or two.  Why do you ask or what signals that use to you? 

Oh, and thanks for the reply.

0 Kudos

Hi @Superfreak3 ,


Can you change the Required Execution Level setting for your setup launcher, and see it works or not.

Try changing to administrator or highest available. More information can be found at the below link:

0 Kudos
Occasional contributor

All of our installations wrapped in a setup .exe have a Required Execution level of As Administrator, however, this package is an .msi.  We did test launching the .msi from an elevated Command prompt, but that too failed.

0 Kudos
Occasional contributor

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.

0 Kudos
Occasional contributor

They are using Microsoft Defender ATP, which is flagging the install.

0 Kudos