I am attempting to open a .MSI installer package file to modify it. Whenever I try to open it, it opens in read-only mode. I see this with Orca, with InstEd, or when opening the file directly via code:
`MsiOpenDatabase()` (ERROR_OPEN_FAILED with MSIDBOPEN_DIRECT or
MSIDBOPEN_TRANSACT persistence modes).
The file itself does not have the read-only attribute set (in fact, has no attributes set)
I am using an account with Administrators group access
As far as I can tell, no other process has the file open
No installs are in progress or suspended
I can copy the file to another location, and open it read/write there. But the original, I cannot touch
Thanks in advance for your help.
My guess is that this is caused by one of the following factors:
Custom NTFS access rights - defined for the file in its security descriptor
The file might be "blocked" - marked with a special flag after being downloaded via Internet Explorer.
The resolution for the latter is to right click the file and select properties and click the unblock button at the bottom of the property page and pressing OK.
The resolution for custom NTFS rights are done in a similar way by going into the security
tab of the property page for the file, but it is easier just to copy and paste the file and use the fresh copy with the default security.
Found it.
#Glytzhkof, you almost had it but there's a detail I did not know about, and left out. This is a package that lies in a folder under "access protection" by my system's anti-virus program: a filesystem hook that blocks modification of critical system and AV files. Turn off access protection temporarily, and the file is wide open.
Fortunately, one of my teammates had some experience with this, and suggested I try it. Bingo.
Thanks, all.
What I have done to get it working was to create first a backup of the MSI file, and then open that backup. It worked for me
Try to close/kill processes that might interfere, for example:
Other running Install shield instances
Installshield updater
Installshield licensing service
Antivirus
Related
I am trying to use IIS Express 8 for a MVC site in VS2012. I am getting the following error whenever I attempt to create the site:
Filename:
\?\C:\Users\xxxxxx\Documents\IISExpress\config\applicationHost.config
Error: Cannot write configuration file
Is there some way to force IIS Express to use a different location for the config & logs folders? I understand I can point to a different location when I am running iisexpress.exe from the command line, but I have no control over this when using Visual Studio.
Alternatively, has anyone got any suggestions why the error is happening? (Side note: My laptop is in a corporate environment which has some stupid encryption on the "Documents" folder, however I haven't had any problems with other software that saves to this location. I also have given the "Everyone" group full access to the folder.)
EDIT - After following the instructions at http://learn.iis.net/page.aspx/1286/iis-80-express-readme/ I still can't seem to get this working. I've tried the following:
Added HKCU\Software\Microsoft\IISExpress\CustomUserHome registry key pointing to my alternate directory
Added HKCU\Software\Microsoft\IISExpress\8.0\CustomUserHome registry key pointing to my alternate directory
Added HKLM\Software\Microsoft\IISExpress\CustomUserHome registry key pointing to my alternate directory
Added HKLM\Software\Microsoft\IISExpress\8.0\CustomUserHome registry key pointing to my alternate directory
Setting the %IIS_USER_HOME% environment variable pointing to my alternate directory.
Any other suggestions?
#Brad
I had your same problem just now. Removing the encryption on the IISExpress folder and the "Read Only" attribute solved it. In my company Documents is also encrypted, but I don't think removing that encryption from IISExpress would be a problem of any sort.
Hope this helps.
I had a very similar error message caused by a completely different problem.
The Error:
C:\VS\TFS_Projects\SomeSolution\SomeProject\SomeProject.csproj : error : Creation of the virtual directory http://localhost:55063/ failed with the error: Filename: \\?\C:\VS\TFS_Projects\SomeSolution.vs\config\applicationhost.config
Error: Cannot write configuration file due to insufficient permissions
More Details: I couldn't even open the project, as opening it would fail.
I could get prior changesets, and they would actually open fine, but if I got latest the projects couldn't be opened.
Solution: In my case, it turned out that when we changed TFS servers, someone had added the ".vs" folder to source control along with everything else. Under which, one developer had his applicationhost.config set up to run sites on a D:\ drive, while I had no such D:\ drive (well, it was a DVD drive.) I was able to get this working by finding a prior changeset with the un-altered applicationhost.config and replacing my local file. (I could have attempted to actually delete the folder, but I didn't go that route.)
Afterwards, we removed the ".vs" folder from source control.
(I put this solution here because it's where google landed me, so other people having this error message might find the above solutions don't fix it for them, and thus they might be having this problem.)
I'm also in a corporate environment with Encryption on the users folder, and removing encryption and removing the read only flags on everything in the IISExpress folder worked for me.
I'm using Visual Studio 2017 on Windows 10 and to fix this problem I had to disable the OneDrive setting "Save space and download files as you use them". After changing the setting my computer crashed but after rebooting I was then able to change SSL Enabled and everything worked.
For anyone googling this; this might be the same problem as this: http://connect.microsoft.com/VisualStudio/feedback/details/878812/use-iis-express-is-broken-in-vs-2012-on-windows-8-1
You can check it by downloading Prcocess Monitor and run it with a filter for "Path" contains "\Documents\IISExpress\config" and then try to change the project to use IIS Express. If there is a CreateFile entry with the result 0xC0190052 as one of the last entries then this is the same issue.
After struggling with this, and verifying encryption and read-only attributes, and having them not work, my solution ended up being:
Navigate to the folder containing the IISExpress folder (in my case, it was in my OneDrive, not Documents folder)
Right click on IISExpress folder > Security tab > Advanced button
Change Owner to yourself, even if it already is
Check the "Replace owner on subcontainers and objects" box
This may not appear until you've completed the Change owner dialog
Open the IISExpress folder
Right click on config folder > Security tab > Advanced button
Add a user > Add principal
Change location to local machine (and not a domain)
Enter the name NETWORK SERVICE and "Check Names"
Press OK to get back to the Advance Security dialog
Make sure to check "Replace all child object permission entries with inheritable permission entries from this object"
Worked in Windows 10 with IISExpress 10, for both VS 2013 and VS 2017.
C:\Users\xxxxxx\Documents\IISExpress\config\applicationHost.config
Uncheck the read-only attribute from the file. It worked for me.
Adding the registry entry seemed to work, however, using environment variables in the registry entry did not. In my environment only our documents directory is redirected, so I simply wanted to move the IIS Express config directory up one level to the %USERPROFILE% directory. However, that did not work. IIS Express read the environment variable literally and of course failed to run.
I had the same issue before, running VisualStudio as Administrator (Run as Administrtor) resolved the issue.
I also had the problem and tried to fix it with setting the registry key in HKCU\Software\Microsoft which didn't work.
The error I made, was using HKCU because, since I do not have permissions to edit the registry under by normal account (which I use to run visual studio), I was using an administrative account. Then of course, HKCU was for that account.
So I just used HKEY_USERS\"my normal user's SID" instead and, when starting iisexpress.exe manually, it created its files at the location indicated. What still didn't work was using iisexpress from visual studio. It still seemed that VS didn't use the registry setting at all.
Finally I resorted in setting a non UNC path for Shell Folders\Personal and User Shell Folders\Personal in HKU\"my normal user's SID"\Software\Microsoft\Windows\CurrentVersion\Explorer\ which did the trick.
I received the same error but in a different context. Opening a project (.csproj file) provided by another developer returned this error and failed to do anything:
Creating of the virtual directory http://localhost:58753/
failed with the error:
Filename: \?\C:\Users\xxxxx\Documents\Clients\xxx\Gen
II\xxx\,vs\config\applicationhost.config
Error: Cannot write configuration file
I removed both Encryption and the R/O attribute from the directory containing the project files and applied to all subfolders and files. Visual Studio can now read the project.
In my case I moved the folder to another location, so I had to edit the applicationhost.config file and changed the virtualdirectory entry to the new location. Removing encryption and setting read only off did not help. I imagine if I had just copied it instead of moving it, it would have happily continued working.
I am trying to open a .chm file.
I downloaded the source, extracted it, and double clicked on Waffle.chm and clicked "Open" but no matter what element in the chm file I click, I get the message:
Navigation to the webpage was canceled.
What you can try:
Retype the address.
What's going on here?
Summary
Microsoft Security Updates 896358 & 840315 block display of CHM file contents when opened from a network drive (or a UNC path). This is Windows' attempt to stop attack vectors for viruses/malware from infecting your computer and has blocked out the .chm file that draw data over the "InfoTech" protocol, which this chm file uses.
Microsoft's summary of the problem: http://support.microsoft.com/kb/896054
Solutions
If you are using Windows Server 2008, Windows 7, windows has created a quick fix. Right click the chm file, and you will get the "yourfile.chm Properties" dialog box, at the bottom, a button called "Unblock" appears. Click Unblock and press OK, and try to open the chm file again, it works correctly. This option is not available for earlier versions of Windows before WindowsXP (SP3).
Solve the problem by moving your chm file OFF the network drive. You may be unaware you are using a network drive, double check now: Right click your .chm file, click properties and look at the "location" field. If it starts with two backslashes like this: \\epicserver\blah\, then you are using a networked drive. So to fix it, Copy the chm file, and paste it into a local drive, like C:\ or E:. Then try to reopen the chm file, windows does not freak out.
Last resort, if you can't copy/move the file off the networked drive. If you must open it where it sits, and you are using a lesser version of windows like XP, Vista, ME or other, you will have to manually tell Windows not to freak out over this .chm file. HHReg (HTML Help Registration Utility) Utility Automates this Task. Basically you download the HHReg utility, load your .chm file, press OK, and it will create the necessary registry keys to tell Windows not to block it. For more info: http://www.winhelponline.com/blog/fix-cannot-view-chm-files-network-xp-2003-vista/
Windows 8 or 10? --> Upgrade to Windows XP.
"unblocking" the file fixes the problem. Screenshot:
Win 8 x64:
just move it to another folder or rename your folder (in my case: my folder was "c#").
avoid to use symbol on folder name. name it with letter.
done.
In addition to Eric Leschinski's answer, and because this is stackoverflow, a programmatical solution:
Windows uses hidden file forks to mark content as "downloaded". Truncating these unblocks the file. The name of the stream used for CHM's is "Zone.Identifier". One can access streams by appending :streamname when opening the file. (keep backups the first time, in case your RTL messes that up!)
In Delphi it would look like this:
var f : file;
begin
writeln('unblocking ',s);
assignfile(f,'some.chm:Zone.Identifier');
rewrite(f,1);
truncate(f);
closefile(f);
end;
I'm told that on non forked filesystems (like FAT32) there are hidden files, but I haven't gotten to the bottom of that yet.
P.s. Delphi's DeleteFile() should also recognize forks.
The definitive solution is to allow the InfoTech protocol to work in the intranet zone.
Add the following value to the registry and the problem should be solved:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001
More info here: http://support.microsoft.com/kb/896054
Go to Start
Type regsvr32 hhctrl.ocx
You should get a success message like:
" DllRegisterServer in hhctrl.ocx succeeded "
Now try to open your CHM file again.
other way is to use different third party software. This link shows more third party software to view chm files...
I tried with SumatraPDF and it work fine.
I fixed this programmatically in my software, using C++ Builder.
Before I assign the CHM help file, Application->HelpFile = HelpFileName, I check to see if it contains the "Zone.Identifier" stream, and when it does, I simply remove it.
String ZIStream(HelpFileName + ":Zone.Identifier") ;
if (FileExists(ZIStream))
{ DeleteFile(ZIStream) ; }
There are apparently different levels of authentication. Most articles I read tell you to set the MaxAllowedZone to '1' which means that local machine zone and intranet zone are allowed but '4' allows access for 'all' zones.
For more info, read this article:
https://support.microsoft.com/en-us/kb/892675
This is how my registry looks (I wasn't sure it would work with the wild cards but it seems to work for me):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"
As an additional note, weirdly the "UrlAllowList" key was required to make this work on another PC but not my test one. It's probably not required at all but when I added it, it fixed the problem. The user may have not closed the original file or something like that. So just a consideration. I suggest try the least and test it, then add if needed. Once you confirm, you can deploy if needed. Good Luck!
Edit: P.S. Another method that worked was mapping the path to the network locally by using mklink /d (symbolic linking in Windows 7 or newer) but mapping a network drive letter (Z: for testing) did not work. Just food for thought and I did not have to 'Unblock' any files. Also the accepted 'Solution' did not resolve the issue for me.
Moving to local folder is the quickest solution, nothing else worked for me esp because I was not admin on my system (can't edit registery etc), which is a typical case in a work environment.
Create a folder in C:\help drive, lets call it help and copy the files there and open.
Do not copy to mydocuments or anywhere else, those locations are usually on network drive in office setup and will not work.
I have an addin program that works with MS Word (version 2007). It is located in the C:\Program Files location. I installed Windows 7 and then went to make a routine change to my files in this location and it would only bring up a read only file. How can I grant myself permission to write to my own program? I cannot change this location or use any other workaround. I have this product out to 25 different companies and I can't change the programming to work from any other location. Thanks
You could also embed a manifest in your EXE that makes your program require adminrights on Windows 7 / Vista.
On Windows Vista, UAC means that users run without admin rights and don't have write access to the program files directories.
The correct solution is to write to a folder for which standard users do have write permissions.
The solution you are looking for is to make your app's folder within program files writeable to all users. You can do this by adding a DACL when installing. It is extremely bad practice to allow standard users to write inside the program files directory and I urge you instead to re-code your app so that it does not need to write there.
Assuming you're doing this as part of modifying the config (and not when your application is running for regular users)...
Your user account probably doesn't have the correct permissions to write/modify the file. Assuming your account is an administrator account, right-click the file, select "Properties". Click the "Security" tab. Click edit and give your user account Full Control.
If you can't do this, it's probably because the ownership of the file doesn't allow you. If this is the case, click on "Advanced", go to the "Owner" tab, and click "Edit".
However, if it needs these permissions when it's running, you should instead be using the %AppData% folder.
Last few days i have been working on building an application to hide folders(thanks to the paid versions of such softwares). After a heavy googling I zeroed into some shell script that would first create a folder and then rename the folder to "Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}". It would then hide this folder by using the command attrib -s -h Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}. The funda behind this is to make it a system folder and hide it. But if you would uncheck the Hide sytem folders in Folder option the control panel becomes visible. I would like to make this folder completely invisible as how the other folder protecting softwares do.
Can somebody throw some more light on this?
Thanks a ton...
Most folder hiding software works by implementing either an extension for Windows Explorer or a file system filter driver.
The first method means that certain items will not be visible when browsing folders in Windows via the UI, but will still be visible to other software and via the command prompt. For example, the Recycle Bin and Temporary Internet Files folders work this way.
The file system filter driver method proxies calls between Windows and the underlying file system and only allows certain requests through. This is similar to how virus scanners prevent access to infected files.
The general idea is that you hook the file system API's and filter out the file system entries you want to hide.
But JelloMonkey is right - this is rootkit behavior and you will get flagged as malicious by rootkit detectors for this kind of behavior. That's likely to get your entire directory quarantined or deleted.
This problem crops up every now and then at work. Our build machine can have it's files accessed via a normal windows file share. If someone browses a folder remotely on the machine, and leaves the window open overnight, then the build fails (as it has done now). The explorer window left opened points at one of the sub folders in the source tree. The build deletes the source, and does a clean checkout before building. The delete is failing.
Right now, I'd like to get the build to work. I'm logged in from home, and I'd rather not reboot the build machine. I'm unable to get hold of the person whose machine is looking and the files, and I can't remotely reboot their machine.
When a windows share has a lock, the locking process is System, so I don't think I can kill it, as with normal locks.
Does anyone know a way to release the lock on a shared folder without having to reboot the machine?
If you are admin on the server sharing the file over the network, you can use the Windows in-built feature:
Start → My Computer → Right-click → Manage gets you to the Computer
Management console
In the left nav, navigate to Systems Tools → Shared Folders
You can view Shares, Sessions & Open Files here. This allows you to find out who has opened which files from which workstations.
Right-click on an item in the list to be able to remove the file lock.
Hope this helps.
Found a solution.
Find the process using Process Explorer:
Download and extract procexp.exe
In Process Explorer use the "Find Handle or DLL..." command from the "Find" menu
Enter in the name of the directory which is having trouble deleting
A list of open files which match that name should be shown. Take some guesses and find which one is failing to be deleted. If the file is locked by a windows share, the process holding the file will be System
Note down the directory which was left open
Download and install the Unlocker (Warning: Link removed, as it contains malware)
Install Unlocker, disabling the option for Explorer extensions and other junk
Unlock the directory
Open up a cmd window, and navigate to C:\Program Files\Unlocker
From the cmd window, run Unlocker.exe "the-path-to-the-locked-folder"
A dialog will pop up confirming the lock release. Use the unlock button to unlock the file
Now the directory should be unlocked, and can now be deleted.
Try Process Hacker:
https://wj32.org/processhacker/
Process hacker is like Process Explorer on steroids.
To find the offending process, press CTRL+F or click the "Find Handles of DLLs" button and search for the file name.
Once you find the file in the find handles dialog, you can simply right click the file there and choose "close". (at least for v2.39.124)
Older versions had a "terminator" option in the context menu of the process.
Right click on the offending process --> Miscellaneous --> Terminator --> Select termination techniques. Note that some are possibly dangerous and may have unintended consequences.
I've had similar problems, and none of these suggestions I've seen above look suitable for automated overnight builds (as the original poster implied) because they all require manual effort to hunt down and kill the locks.
The only method I've tried that seems to work reliably is to remove the share itself, make the build, then add the share back. Here's one way of removing the share automatically:
D:\Projects>net share Projects /DELETE /Y
Users have open files on Projects. Continuing the operation will force the files closed.
Projects was deleted successfully.
(NOTE: Creating the share again automatically can be a pain if the privilege groups you need to give it are messy.)
The way i do it is by using both OpenFiles.exe and Handle.exe
You can run them in any order and you will have your resource fully unlocked.
OpenFiles: to disconnect File Sharing sessions
Handle.exe: to release any open handles (don't try to close handles belonging to pid4, since that's the system process)
You can automate this by using powershell, batch, or any language of your choice.
Another option is, starting from Windows Vista, to use the Windows tool built into the system:
monitor resources: perfmon.exe /res
Extracted from: Http://www.sysadmit.com/2017/06/windows-how-to-know-that-process-has-open-a-file.html