Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
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:
@echo offtitle Resetting ACLs...
echo.echo Determine whether we are on an 32 or 64 bit machineecho.
if "%PROCESSOR_ARCHITECTURE%"=="x86" if "%PROCESSOR_ARCHITEW6432%"=="" goto x86
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
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 changeecho the values named YOURUSERNAME to be the Windows user account thatecho 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.txtecho. echo. subinacl.exe /keyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /setowner=administrators >> %temp%\subinacl_output.txtecho. 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.txtecho. 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.txtecho. echo. subinacl.exe /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txtecho. echo. subinacl.exe /keyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators >> %temp%\subinacl_output.txtecho. echo. echo System Drive...subinacl.exe /subdirectories %ProgramFilesPath%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txtecho. echo. echo Windows Directory...subinacl.exe /subdirectories %windir%\ /grant=administrators=f /grant=system=f /grant=users=e >> %temp%\subinacl_output.txtecho. echo. echo ==========================================================================echo. echo FINISHED.echo. echo Press any key to exit . . .pause >NUL
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 failed30.875: Access is denied.
30.844: DoRegistryUpdates:UpdSpInstallFromInfSection Failed for MSI.Reg.Install: 0x5 30.844: DoInstallation:DoRegistryUpdates failed30.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>
Using the subinacl tool has solved this similar problem on my HP Pavillion Media Center running Vista Home Premium which I first ran into after installing Pinnacle software for use with a Pinnacle Show Center ( and this was with UAC enabled). It has recurred a few more times all related to installing other sorts of media server related software. I still cannot get beyond the Media Center receiver Service (ehRecvr.exe) form continuosly crashing and the Hauppauge tuner card can no longer be found in the MS Media Center, even though it works perfectly with WinTV.
BUT these issues are not what I want to call attention to here (I just mentioned them in case other see similar problems or can suggest anything)
What I really want to point out are some of the side effects of running the above script using subinacl.exe on a Vista system which has more than one user login. If you have several family members and multiple logins on your initial login screen, these logins (except for your Administrator member Accounts) will disappear after running the above script.
I was completely stumped when I saw mine had vanished, but yet I could still see all of them in the Control Panel under User Accounts. I found a simple solution to bring them back by simply running 'net localgroup User /ADD username' for each. HOWEVER, I still run into all kinds of permissions issues with various applications and service, like printing, etc. which require their own varied security settings.
I have added this to the script to help out on some of this, but there is still something missing
for %%i in (TYPE YOUR USERNAMES HERE) DO (
echo Fix USER: %%i
net localgroup Users /ADD %%i
subinacl /subdirectories c:\Users\%%i /grant=administrators=f /grant=system=f /grant=%%i=f /grant=Users=r
I don't know if grant=r is enough for regular Users or what other permissions need to be reinstated to get things completely back to normally.
So what I'm saying here is that you may think everything is great again after running these subinalc commands, but I guarantee something will turn up somewhere, and things become a lot more complicated when you have multiple user accounts.
What I really wish we had was some sort of permissions map which states what permissions should be assigned for what and whom by default on a vanilla install. Trying to figure this out by tweaking this and that (which is what I have been doing) is much too dangerous. This seems to be a half-baked permissions scheme which breaks and falls apart with little effort and there has been provided no patch to correct it. This horrible experience has caused me to discourage anyone who asks from moving to Vista. It is unreliable and I wouldn't be able to help them, if they ran into his problem, with much confidence.
this command is the culprit for disabling my user accoutns...
secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose
and it is not referenced in the above script of subinacl commands.
However, the permissions issues that I pointed out still apply when you have multiple logins on Vista.
Recently had a similar issue and am unable to resolve it. I'm taking the liberty of pasting a full description of the issue as posted on my forum. As stated in the text, the SubInACL tool did not help (btw, when I ran it I noticed severl "error" messages, the the utility did run to completion. Here's the issue - any assistance will be greatly appreciated:
Over the weekend I tried to upgrade my setpoint software to the latest release. After installation I opened setpoint to find there were no tabs - either for the mouse or the keyboard. Spoke with Logitech and they asked me to do a selective startup. When I tried to do so I received the following message from msconfig:
"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."
Logitech says that's the problem - setpoint will only install when logged into an Admin account. I am the only user and am logged on with full admin rights. I then went to my office system and got the exact same message when I tried to do a selective startup. My first thought was that it might be some services I disabled - so I changed them all to default XP Pro settings - didn't help. Other things I've tried:
Ran the SubInACL tool to repair file and registry permissions
Per a suggestion on the web I changed an HP registry setting
Tried making the changes from Safe Mode
Ran full scans with AV, AdAware & SpyBot
BTW, I do not use ZA
Bottom line, I still get the same error message in msconfig on both systems and still cannot install the latest setpoint sw. I have a current Acronis image of my system partition and have been reverting to that after each unsuccessful attempt
Hi Allan1 - The SubInAcl commands that I list above in this blog post are not guaranteed to fix all possible access denied errors on a system. Specifically, it only changes the permissions on some files/folders and some parts of the registry. It does not make any changes to service permissions. You may need to try to manually correct any remaining permission issues on your system.
One other thing I should note here - if you get an access denied error, it does not necessarily mean that the account you're logging in with is not a member of the Administrators group on your system (as its seems to be implied by the Logitech error message above). It means that whatever account you're logged in with doesn't have sufficient permissions to whatever resource the system is trying to access. Not all resources on a system are accessible even by administrators, plus permissions can be changed by other software or by the user.
Also, selective startup mode does not cause the logged in user to no longer be a member of the Administrators group.
I'd suggest trying to contact Logitech again to find out exactly what files, registry and/or services are being accessed when you tryt o start your software and see if they can walk you through steps to fix the permissions manually.
I have some good news, and some so-so news.
Always starting off with good news: SubInACL works on Vista x64 (in this case, Ultimate).
So-so news: I think I also discovered a bug related to depth.
My HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID branch is huge. (Well, so is Classes.) At some point, the path name printed during the progress message starts to be inaccurate; the Wow6432Node starts repeating in the display, but it does work (based on the last messages after a ^C). But eventually SubInACL crashed. I was able to specify just Classes and it eventually worked (after about 4 million updates). I manually updated the other Wow6432Node branches.
I'm happy to report that this has cleared up the 80070005 and 8020(something or other) errors that I've been having with Automatic Update.
Okay, here's an update.
First, after some trial and error (and several hours on the phone with Logitech) I was able to install Setpoint 4.00 (not the latest version, but close enough). Turns out it had nothing to do with permissions or rights.
Second, a couple of us have done some trial and error and we think the message in msconfig may be related to systems that have .Net Framework 2.0 (SP1) or higher installed.
Last, when all is said and done it appears that the system will indeed still boot to diagnostic mode even though that message is displayed.
Thanks so much for taking the time to respond and for this superb thread and tutorial :)
Hi Allan1 - I'm glad you were able to get this software to work, but I'm sorry for all of the hassles you had to go through. What was the underlying issue in this scenario?
One comment - I don't know of any dependencies between MsConfig and the .NET Framework. MsConfig should work fine regardless of whether or not you have any versions of the .NET Framework installed on your system.
There were a couple of things. First, Logitech support told me that Setpoint versions newer than 4.00 and had me download that version from their FTP site. Second, I had to rename a specific file in \windows\system32\drivers (wdf01000.sys) to a non-usable name (ie, .bak) and then plug in the dongle for the new mouse (XP would not install the HW if that file existed). I still got a "could not complete HW install) at this point, but upon reboot XP did report finishing the hw installation(it recognized the new mouse and installed the new wdf01000.sys driver file - same version as the old one). Then I installed the setpoint sw and it did recognize both the new mouse and my old keyboard. Logitech acknowledges the problem I had (no tabs after upgrading to Setpoint 4.x) is not uncommon and they can generally get it to install with some known work-arounds, but they say my problem was a little more sever than most. They did make note of the steps I had to take to get it to work and entered the "fix" in the DB.
As for .Net Framework and msconfig I agree - there should be no issue. But we've found the problem exists on those systems where we have ver.2 (sp1) installed and does not appear on other systems. Could be coincidence I suppose.
I followed the instructions to setup and run SubInACL but I am unsure that what I am seeing is success.
When I run it, and the window is open there is a red bar across the top showing "Done:, Modified and Failed. It seems that the same number that were modified also failed. Is this what I should be seeing or did I do something wrong?
Hi Firecop1 - I haven't heard of SubInAcl displaying this type of information in the past. Would it be possible for you to post a screen shot of what you're seeing?
Also, did you try to run SubInAcl because you received an "access denied" error while trying to install a product on your system? If so, did you try to re-run that product setup after running SubInAcl to see if it helped?
Hey Aaron, i had the same type of display that firecop1 talks about, but out of all of the registry entries shown, it only threw up 3 errors. I believe you may get this "red bar" screen when it is actually modifying registry entries, as i had a lot of those. Anyway, I do have a screenshot of what it looks like, but don't know how to post it here, but I'll gladly send it if you'd like.
SubInACL did fix my problem, which was a failing Windows Update for KB885836 that has stumped me for the last 6 months. I noticed a lot of other folks have this same type of problem with other Windows Updates, so I downloaded and tried to manually install KB885836 which is when it gave me the registry permission denied error code 5, that led me to your awesome article/application!
Thanks a bunch, my machine is fully patched again.
firstname.lastname@example.org... thank you so much for that comment! The original reset.cmd in the blog post totally killed my Vista install. Not even System Restore would work. Thankfully I took an image of my entire drive using a 3rd party tool before running it!
After restoring my drive, I ran your version of the script and everything works brilliantly now! No more access denied registry warnings when trying to install and run certain software. Thanks!!
re: Solving setup errors by using the SubInACL tool to repair file and registry permissions
I am running Vista Ultimatex64 & I am having the same issues. Could someone please tell me how to "specify" Just Classes & Manually Update all the Other Now6432Node Branches???
Hi Grzyb - When you install the SubInAcl tool, it also installs a readme file to the location C:\Program Files\Windows Resource Kits\Tools\subinacl.htm. That readme provides detailed usage information, including how you can specify exact sub-keys to update. Hopefully this will help in your scenario.
Hello at all,
i have the 80070005 Update Problem at Vista, so i tryid this, installed SubInAcl successfully, but when i run the reset.cmd, i get syntx errors for every line, like this:
Error when checking arguments - HKEY_Local_Machine
any solutions to this?