Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

Solving setup errors by using the SubInACL tool to repair file and registry permissions

Solving setup errors by using the SubInACL tool to repair file and registry permissions

Rate This

A while back, I wrote a blog post about a .NET Framework 2.0 beta 2 installation problem that was caused by incorrect access control list (ACL) permissions on some registry hives.  In that post, I described how to use a tool in the Windows Resource Kit named SubInACL to reset file and registry ACLs to help solve this problem.

Ever since I wrote that post, I have run into installation errors for several other products that have been solved by using the SubInACL tool.  Therefore, I wanted to write a standalone set of instructions for how and when to use the SubInACL tool because the previous blog post is specific to the .NET Framework 2.0 setup and does not always appear in search results when people run into this kind of a problem and search the Internet for assistance.

How to download and run SubInACL

Here are some steps that can be used to download and run the SubInACL tool to repair file and registry permissions that are often needed to successfully install programs on Windows, particularly for MSI-based (Windows Installer) setups:

  1. Download the SubInACL tool and install it.  By default it will install to c:\Program Files\Windows Resource Kits\Tools
  2. If you are running Windows Vista, click on the Start menu, choose All Programs, then Accessories, then right-click on the item named Command Prompt and choose Run as administrator
  3. If you are running an OS other than Windows Vista, go to the Start menu, choose Run, type cmd and click OK
  4. In the cmd prompt, type notepad reset.cmd and click yes to open Notepad.exe and create a new text file named reset.cmd
  5. Copy and paste the following contents into reset.cmd (or download it from this location on my file server and rename it from reset.cmd.txt to reset.cmd):

    @echo off
    title Resetting ACLs...

    setlocal

    echo.
    echo Determine whether we are on an 32 or 64 bit machine
    echo.

    if "%PROCESSOR_ARCHITECTURE%"=="x86" if "%PROCESSOR_ARCHITEW6432%"=="" goto x86

    set ProgramFilesPath=%ProgramFiles(x86)%

    goto startResetting

    :x86

    set ProgramFilesPath=%ProgramFiles%

    :startResetting

    echo.

    if exist "%ProgramFilesPath%\Windows Resource Kits\Tools\subinacl.exe" goto filesExist

    echo ***ERROR*** - Could not find file %ProgramFilesPath%\Windows Resource Kits\Tools\subinacl.exe. Double-check that SubInAcl is correctly installed and re-run this script.
    goto END

    :filesExist

    pushd "%ProgramFilesPath%\Windows Resource Kits\Tools"

    echo.
    echo Resetting ACLs...
    echo (this may take several minutes to complete)
    echo.
    echo IMPORTANT NOTE: For this script to run correctly, you must change
    echo the values named YOURUSERNAME to be the Windows user account that
    echo you are logged in with.
    echo.
    echo ==========================================================================
    echo.
    echo.
    subinacl.exe /subkeyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators > %temp%\subinacl_output.txt
    echo.
    echo.
    subinacl.exe /keyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators >> %temp%\subinacl_output.txt
    echo.
    echo.
    subinacl.exe /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f /grant=users=r /grant=everyone=r /grant=restricted=r /setowner=administrators >> %temp%\subinacl_output.txt
    echo.
    echo.
    subinacl.exe /keyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f /grant=users=r /grant=everyone=r /grant=restricted=r /setowner=administrators >> %temp%\subinacl_output.txt
    echo.
    echo.
    subinacl.exe /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txt
    echo.
    echo.
    subinacl.exe /keyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txt
    echo.
    echo.
    echo System Drive...
    subinacl.exe /subdirectories %ProgramFilesPath%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txt
    echo.
    echo.
    echo Windows Directory...
    subinacl.exe /subdirectories %windir%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txt
    echo.
    echo.
    echo ==========================================================================
    echo.
    echo FINISHED.
    echo.
    echo Press any key to exit . . .
    pause >NUL

    popd

    :END

    endlocal

     
  6. Change the values named YOURUSERNAME to be the Windows user account that you are logged in with.

    Note:  The YOURUSERNAME value should match the name of your user folder at c:\Documents and Settings (or c:\users on Windows Vista and higher).  You can also find the value to use for YOURUSERNAME by launching Task Manager and looking at the user name listed in the User Name column of the Processes tab.

  7. Save and close reset.cmd. 
  8. In the cmd prompt, type reset.cmd and press enter to run the SubInACL tool.  This tool will take several minutes to run, and it requires that the user account you are using has administrator privileges on the system.  This is why it is necessary to run it from an elevated cmd prompt on Windows Vista.  Step 2 above can be used to start an elevated cmd prompt on Windows Vista.
  9. After reset.cmd completes, try to install the product that previously failed to install correctly on your system.

Note: There are a couple of scenarios where installing or running SubInAcl can fail.  For example, some non-English versions of Windows have the name of the Administrators group translated to another language, and the command lines listed above will fail in that case.  I have posted workarounds for the issues that I know of in this separate blog post.

Also note: Running the above command lines will cause SubInAcl to create a log file named %temp%\subinacl_output.txt.  If you see any errors reported in the cmd prompt after running SubInAcl, you can look in this log file for more detailed information about what file(s), folder(s) or registry value(s) are causing the errors.  To open this log file, you can click on the Start menu, choose Run, type notepad %temp%\subinacl_output.txt and click OK.

When looking at this log file, you may see some errors reported with error code 5.  That error code means Access Denied, and it is typically caused by Windows or some other program running on your system that is holding files, folders or registry values in use so that SubInAcl is unable to update the permissions for them.  Most of the time, that type of error in the SubInAcl output can be safely ignored, but you may need to try to reboot and then manually fix the permissions for these files, folders or registry keys as a workaround.

When is SubInACL useful

I have found that the SubInACL tool is most useful when a setup package fails with error code 5 or 0x5 or 0x80070005.  All of these error codes mean Access Denied, and this type of error code is often caused by missing ACLs for the Administrators group or the built-in System account.  The Windows Installer service runs with System account permissions in most cases.  If the System account does not have sufficient permissions to access the file system or parts of the registry, an MSI-based setup package will fail with an Access Denied error.

SubInACL can also help resolve Internet Explorer script errors caused by incorrect access control permissions for specific user accounts on the system.

Example of a setup failure that was fixed by SubInACL

A customer contacted me with a problem installing Visual Studio 2005.  I looked at the main Visual Studio log file located at %temp%\dd_vsinstall80.txt, and I found that Windows Installer 3.1 setup was failing.  Then, I looked at the Windows Installer 3.1 setup log file located at %windir%\KB893803v2.log.  It showed the following error:

30.844: DoRegistryUpdates:UpdSpInstallFromInfSection Failed for MSI.Reg.Install: 0x5
30.844: DoInstallation:DoRegistryUpdates failed
30.875: Access is denied.

I had the customer run the above steps to use the SubInACL tool to update the file and registry ACLs on their system, and then they were able to install Windows Installer 3.1 and Visual Studio 2005 with no further problems.

<update date="11/15/2006"> Updated subinacl command lines to include recursive ACL updating for folders and files under %windir% </update>

<update date="3/22/2007"> Updated the steps to make them easier to follow by moving the directory change into the batch file. </update>

<update date="9/25/2007"> Updated the notes to indicate that some Internet Explorer script errors can be resolved with this tool as well. </update>

<update date="5/30/2008"> Updated command lines based on customer feedback regarding their experiences on Windows Vista. </update>

<update date="6/16/2008"> Updated command lines to cause SubInAcl to create a log file in the %temp% directory in case it is needed for troubleshooting afterwards. </update>

<update date="6/17/2008"> Added a link to a blog post where I describe a couple of workarounds for problems that can occur while trying to install and/or run SubInAcl. </update>

<update date="6/20/2008"> Updated command line to include a backslash after %SystemDrive% in the 2nd to last command. </update>

<update date="6/24/2008"> Updated wording of link to the post for troubleshooting SubInAcl errors to try to make it more visible. </update>

<update date="7/29/2008"> Updated directory ACL command lines to not affect the Documents and Settings sub-folders. </update>

<update date="3/12/2009"> Fixed broken link to reset.cmd. </update>

<update date="4/7/2009"> Added clarification about how to determine the correct value to substitute for YOURUSERNAME in the sample SubInAcl script. </update>

<update date="5/18/2009"> Added clarification about where to run reset.cmd after creating it. </update>

 

  • I can't thank you enough for writing this quide. I was having installation problems which I spent a few days constantly trying to solve. I finally found information telling me to use the SubInACL tool but wasn't told how to create the file named Reset.cmd.

    I have now sorted my problem thanks to your EXTREMELY HELPFUL instructions.

    Thankyou so much!

  • Thanks for your help with this. I too had been days trying to get either dotnet 2 or dotnet 3 to install and they kept stopping on permission errors and I was admin and reset file permissions on the one file with no luck. I used the cleaner and it helped with other problems but this got dotnet 3 working finally !! Great Job...

  • Aaron, Thank you so much for this posting. On the campus I work we have encountered a host of issues. All while I kept think that the issue wasn't this "program" or this "update" or install. You excellent work here has validated what my gut has been telling me.

    Your solution goes to the very root a problem that may plauge more users than I'd care to think about.

    As an analyst in the field, THANK YOU!!

  • Add me to the ranks above lauding your efforts.  I wish I had found this information at least 3 or 4 years ago.  Ever since Visual studio .NET, I've had problems opening websites on my local IIS using FrontPage extensions which I recently found out is caused by registry permissions in HKCR (thanks to researching my IE7 installation problems).  I hope this will either get me straightened out permanently or at least give me a quicker resolution when it happens.

    To give something back, I've enhanced the Cmd batch script above so it's capable of being run without going into a shell or changing directories, so it's easier to give to novice users needing help.  I'm not sure the best way to post this, so I'll paste it here and perhaps Aaron can make it into a link.  (By the way, I called my file ResetACLs.cmd.)  If this gets munged, email me for a copy of the file.

    @echo off

    title Resetting ACLs...

    cd /d "%ProgramFiles%\Windows Resource Kits\Tools"

    echo.

    echo Resetting ACLs...

    echo (this may take several minutes to complete)

    echo.

    echo ==========================================================================

    echo.

    echo.

    subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f

    echo.

    echo.

    subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f

    echo.

    echo.

    subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f

    echo.

    echo.

    echo System Drive...

    subinacl /subdirectories %SystemDrive% /grant=administrators=f /grant=system=f

    echo.

    echo.

    echo Windows Directory...

    subinacl /subdirectories %windir%\*.* /grant=administrators=f /grant=system=f

    echo.

    echo.

    echo ==========================================================================

    echo.

    echo FINISHED.

    echo.

    echo Press any key to exit . . .

    pause >NUL

  • Hi FuzzyBS - Thank you for contributing this updated version of reset.cmd.  I've updated the version on my file share to contain these contents so it will be easier to use in the future.

  • Do you have any guidance on a 64-bit version of SubInAcl?

    It's been over a year, but I seem to recall that it didn't work properly on x64 (at least for registry usage) because it couldn't access the 64-bit registry hive. I asked for a 64-bit version of the tool at the time, and the response was that none were planned. I thought I'd check to see if there was anyone else running into this, or thought towards an x64 version.

  • Hi Mattie - I've never tried SubInAcl on 64-bit systems, but it wouldn't surprise me if it didn't work on that processor architecture.

    On a 64-bit system, you might need to use one of the built-in Windows tools such as cacls to reset ACLs on your system.  You can click on the Start menu, choose run, type cmd and click OK, and then run cacls /? to list usage information for this tool.  Hopefully this will help in your scenario.

  • As an admitted hack (Step 1 of the 12), I am compelled to address you as Mr. Stebner.

    I've been puzzled by the persistant registry errors I received while trying to install IE7. The directions in your post finally fixed the problem. I'm adding my IE7.log with the error string for others that might be encountering the same problem. Thanks again for the excellent advice!

    0.265: ================================================================================

    0.265: 2007/08/08 21:49:11.328 (local)

    0.265: c:\b7a15deb6e2d1a90b811b9a464769875\update\update.exe (version 6.2.29.0)

    0.281: Hotfix started with following command line: /quiet /norestart /er /log:C:\WINDOWS

    2.187: IECUSTOM: Scanning for proper registry permissions...

    2.969: IECUSTOM: Scanning for proper registry permissions...

    3.156: IECUSTOM: Scanning for proper registry permissions...

    3.469: IECUSTOM: Unwriteable key HKLM\SOFTWARE\Classes\Interface\{3B7C8862-D78F-101B-B9B5-04021C009402}

    3.469: IECUSTOM: Unwriteable key HKLM\SOFTWARE\Classes\Interface\{859321D0-3FD1-11CF-8981-00AA00688B10}

    3.484: IECUSTOM: Unwriteable key HKLM\SOFTWARE\Classes\Interface\{E9A5593C-CAB0-11D1-8C0B-0000F8754DA1}

    3.484: IECUSTOM: Unwriteable key HKLM\SOFTWARE\Classes\Interface\{ED117630-4090-11CF-8981-00AA00688B10}

    3.500: IECUSTOM: Backing up registry permissions...

    3.500: IECUSTOM: Unable to backup DACLs HKLM\SOFTWARE\Classes\Interface\{ED117630-4090-11CF-8981-00AA00688B10}

    3.500: IECUSTOM: Finished backing up registry permissions...

    3.500: IECUSTOM: An error occured verifying registry permissions. ERROR: 0x80070005

    3.500: DoInstallation: CustomizeCall Failed: 0x3f5

    3.500: IECUSTOM: Restoring registry permissions...

    3.500: IECUSTOM: Unable to restore DACLs HKLM\SOFTWARE\Classes\Interface\{ED117630-4090-11CF-8981-00AA00688B10}

    3.500: IECUSTOM: Unable to restore DACLs HKLM\SOFTWARE\Classes\Interface\{E9A5593C-CAB0-11D1-8C0B-0000F8754DA1}

    3.500: IECUSTOM: Unable to restore DACLs HKLM\SOFTWARE\Classes\Interface\{859321D0-3FD1-11CF-8981-00AA00688B10}

    3.500: IECUSTOM: Unable to restore DACLs HKLM\SOFTWARE\Classes\Interface\{3B7C8862-D78F-101B-B9B5-04021C009402}

    3.500: IECUSTOM: Finished restoring registry permissions...

    3.500: The configuration registry key could not be written.

    3.500: Internet Explorer 7 installation did not complete.

    3.500: Update.exe extended error code = 0x3f5

    0.375: ================================================================================

  • I'm going to go ahead and preemptively thank you for this - I've been getting this error (with installer 3.1, curiously enough) for *ages* now and until I found this site, no one really had any functional ideas on how to fix it.

    When/if this works, if I ever meetcha in real life, I'm buyin you a pizza and/or beer, whichever you prefer ;)

  • Hi D.cochran - Hopefully these steps will end up working for you.  As my wife can attest - I'm always up for pizza  :-)

  • There is but a single account on my Win XP Pro SP2 notebook, an Administrator account, so of course I am the Administrator. Prior to installing any new software on this notebook I like to temporarily disable all Startup programs by running MSCONFIG, un-checking "Load Startup Items" and clicking OK. I then re-boot and continue with the installation of my new software. Very recently, while this procedure seems to continue to work, it also displays an ominous message, "An Access Denied error was returned while attempting to change a service. You may need to log on using an Administrator account to make the specified changes." A Google search revealed Aaron Stebner’s Weblog for “Solving setup errors by using the SubInACL tool to repair file and registry permissions” as a possible solution to this vexing problem.

    The good news is that Mr. Stebner’s cmd file runs correctly, and breaks nothing. The bad news is that I continue to get that ominous message even though the change I make inside MSCONFIG seems to “take” just fine. That is, I can successfully disable and later re-enable all “Load Startup Items”.

    -

    Peter Sale

    Santa Monica CA USA

  • Hi Psale - I'm sorry for the hassle this is causing for you.  Each object in the OS has specific ACLs assigned to it, including files, registry keys, services, etc.  Even if you're running as an administrator, if your administrator group doesn't have correct ACLs, you won't be able to modify an object.  The SubInAcl tool adds administrator and system permissions for files and registry entries, but it doesn't modify other objects like services.  It is possible that there is a service that you have to manually go and change the ACLs for in order to fix this issue.  You can use a tool like Process Monitor (http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx) to narrow down what object is causing the access denied error.  From there, you should be able to use Windows Explorer or the Services control panel to right-click on the object, choose the Security tab and add the missing ACLs.

  • I encountered a similar problem during the installation of VS2008 on Vista (more exactly, it crashed during the installation of Document Explorer 2008).

    I fixed the problem myself, by writing a small tool that was similar to SubInACL.

    After spending more than one day on fixing the problem, I discovered this nice page. Argh !

    Anyway, here is a way to reproduce the bug, since it appears to be a bug from Vista:

    1) Install Vista on a computer

    2) Create a temporary admin account

    3) Install Visual Studio 2005 or Office with this account (I disabled UAC, but it may be possible to reproduce the problem by running the installer as Administrator).

    4) Use another account, or simply log into a domain

    5) Delete the temporary admin account.

    Now, Vista's registry is completely broken, with a ton of registries giving access denied, even if you are admin.

    In my case, I had 729 broken registries, and it was impossible to manually repair.

  • Beautiful article.  Now to see if it will solve my problems....

    I reproduced JC's scenario above inadvertently - perhaps by trying the easy way to do things - which should work.  

    Had Vista RC1 installed and Office 2007 Beta.  Office Beta expired. Needed quick edits in a web page, Installed Front Page 2003.

    Everything - IE 7, Search, Cntrl Panel -- working.  RC1 Expired.  

    Installed RTM Vista Ultimate.  As an upgrade, which succeeded without complaint. Installed Office 2007.       Left FP 2003 on there.  Ran a little .reg file that turned of the completely inappropriate control over directory appearance in Explorer.  

    Now, IE7 wouldn't start.  Search from the start menu wouldn't start.  Control panel would not show any entries on the so called "Control Panel Home" (but would work in classic view).  Running ProcMon while starting IE7 showed an "Access Denied" followed by a thread exit and then a few thousand more events as it shut down without opening.  I changed the permissions on the questionable key (had to take ownership as others have noted -as admin, not dev, knew this) and now it would start, that is the window would open.  But it was absolutely dead.  Nothing in the window would work.  

    Looked at the reg again - now, a couple subkeys had appeared, and behold, they lacked the proper permissions.  

    Same sort of thing happened when monitoring the attempted start of Search.  10 access denieds.  Monitored a boot sequence: 423 access denieds.  Gave up and started searching for something like this.  Two days of failure - using search on MSFTs site - Live lost the search battle, because Google, not Live, found this blog the fourth entry down.  

    Thanks for the article!

    Whether it works or not....:)    

  • Double plus good beautiful!

    Reported that it took about 2.6 minutes, but took closer to 10.  Changed several hundred thousand entries.  Good lord, no wonder vista needs horsepower- a wonder it works at all.  

    It solved the three problems noted above and also fixed the inability to copy files and directories from another (XP) machine.  AND the failure to find a file when Excel started.  And Access's refusal to start because there was no license on the machine.  

    You the man, you the reg man!  

    PS:

    Note to other msft devs: please learn to think.  Not to code, to think.

    Also learn to write halfway intelligent error messages.  "Access can not start because there is no license on this machine."  That's your error message and it is to stupidly wrong there are no words to describe it.  How about: "this program failed to start because it could not access the following registry key[s]....xxxxx...."  How hard is that?  Jeeez.

    PPs

    Thx again for the article.

Page 1 of 21 (310 items) 12345»
Leave a Comment
  • Please add 8 and 7 and type the answer here:
  • Post