I need help solving the "Provider '' resources not accessible when trying to create a windows event provider. I create my manifest file with the ManGen utility, and name my '.exe' file as my message and resource file. I compile the '.rc' file with my exe file and the expected'.res' file are generated. However, when I run wevtutil I keep getting the 'resources not accessible' warning.
When you install your manifest (e.g. wevtutil im manifest.man), you should see some sort of a warning if the resources aren't available:
**** Warning: Publisher EventsProvider resources are not accessible.
To get some additional information, try to retrieve information on one of the publishers. For example:
c:\...> wevtutil gp <EventProviderName>
Failed to open metadata for publisher <EventProviderName>. Access denied.
Ok, the above suggests a permissions problem, so let me make the path accessible and try again:
c:\...> wevtutil gp <EventProviderName>
Failed to open metadata for publisher <EventProviderName>. The specified resource
type cannot be found in the image file.
For the above, it looks like the resource didn't get compiled in correctly.
If you go File->Open with VS and open your exe in the resource viewer you should be able to see the resources that were compiled in. You should at least have a "WEVT_TEMPLATE" entry.
For the resource to be compiled in correctly, csc needs to be passed the resource as follows:
csc /win32res:<Resource.res>
The dll you are registering needs to have a particular set of file permissions. I suspect that the event logging service runs under the "local service" account. So just giving SYSTEM access rights is not enough. I solved by problem by giving the "USERS" group on my PC "read & execute" priviledges.
I ran into a nasty problem that took a day to track down. I shared my project working folder and then unshared it. For some reason this removed the "USERS" access priviledges. I think this is the reason than the event tracing samples in the windows SDK copy all the dlls to a special folder under the C drive and install the provider from there. When you create folders under C drive the USERS group is given access automatically.
I had the exact same error but the solution was slightly different to the other answers that have already been posted. I had to open the manifest file and change the resourceFileName and messageFileName attributes to use absolute paths to the application executable.
I experienced the similar problem. The solution is to
use absolute paths wherever possible and stay away from relative paths
make sure everyone has read access to manifest files
If your manifest files are called manifest.man and manifest.dll, then
grant read access to everyone
icacls %~dp0\manifest.* /t /grant Everyone:R
use absolute paths to install (%~dp0 variable could be used if you are using a batch file)
wevtutil im %~dp0\manifest.man /rf:"%~dp0\manifest.dll" /mf:"%~dp0\manifest.dll"
Related
As pointed out in Writing config file in C:\Program Files (x86)\MyApp\myapp.cfg, vs. Administrator privilege, it is not a good idea to write a config file in C:\Program Files (x86)\MyApp\myapp.cfg.
Instead of this, my software now saves its data in a subdir of %ALLUSERSPROFILE% (ex : C:\ProgramData\MyApp\myapp.cfg on Win7)
[I use myfile = open(filename, 'a') in Python to do this.]
I now encounter an issue about this file :
I installed the software with User A, and ran it, then the file C:\ProgramData\MyApp\myapp.cfg was written.
Then, I changed user to User B, and ran my software again : now an error is displayed : User 2 has no right to write in C:\ProgramData\MyApp\myapp.cfg (Permission denied).
Why? Isn't %ALLUSERSPROFILE% a place that can be written by all users?
How to solve this problem ?
No, C:\ProgramData, aka FOLDERID_ProgramData, has restricted security settings. Standard users can create files there. But these files are, by default, secured so that only the user that created the file can subsequently modify the file.
The recommended solution is for your installer to create a sub directory of C:\ProgramData for your shared storage. And that sub directory must be given a permissive ACL by the installation program. That is what grants the desired access to all standard users.
I do wonder whether you really need shared writeable data. Normally I'd expect to see shared configuration be something that is specified at install time and modified infrequently by administrators. Most configuration data tends to be per user.
I'd like to add onto this as I was having issues writing to C:\ProgramData as well. My issue ended up being that my directory/files within C:\ProgramData were written by an administrator. When my app ran under a normal user it was unable to write there so Windows automatically used C:\Users\fooface\AppData\Local\VirtualStore\ProgramData instead. I found the path it was writing to by using process monitor on my application. After seeing this I deleted the files out of C:\ProgramData and ran my app again and it wrote there as expected.
Hope this helps someone.
I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe:
app.exe
add.exe.config
logs (folder)
I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.
It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. #Ken White provided a very good pointer to an existing StackOverflow answer about this.
If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.
An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.
Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.
Using DirectoryInfo on a path you can then get the security data from GetAccessControl.
When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.
Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.
You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.
Hope this helps
paul
This generally all depends on:
Whether your app requires to be run as administrator for other reasons and..
Whether your app is provided for limited users.
If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.
If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
How can I consume a registration free COM object without copying the dll to the same directory as the executable? Is this possible?
I would like a complete working sample or a detailed step-by-step guide for my exact scenario.
For example, I have the following components:
CppTestRunner.exe - vc++ console application
CppTests.dll - vc++ mfc dll
CsCOMServer.dll - c# COM visible dll
I do not want to modify the exe or its directory, like adding an external manifest.
CppTests.dll is in a different directory than the exe.
It is okay if CsCOMServer.dll is in the same directory as CppTests.dll.
CppTestRunner.exe calls LoadLibrary on CppTests.dll which works fine.
After embedding manifests and using the windows activation context apis, I was able to copy CsCOMServer.dll to the exe directory to verify that CppTests.dll can create an instance of CsCOMServer.dll without issues, but again, I am trying to avoid this step.
Currently, with CsCOMServer.dll in the same directory as CppTests.dll, and without CsCOMServer.dll in the exe directory, I am getting the following error when I call CoCreateInstance:
Error = 0x80070002 The system cannot find the file specified.
I have used sysinternals process monitor to track down the paths CppTestRunner.exe looks in, etc.
I notice that depending on the things I try to do, sometimes CppTestRunner.exe tries to read CsCOMServer.dll.config in the same directory as CppTests.dll, but no matter what I try to put in there, I was not able to get past the error.
Also depending on other things I try to do, CppTestRunner.exe tries to read CsCOMServer.dll in the same directory as CppTests.dll but for some reason, I still get the same error.
Anyone know of working code with this exact scenario?
As you can probably tell, this is part of some unit\integration tests.
As a simple workaround, I am currently copying CppTestRunner.exe to the same directory as CppTests.dll and running it from there, but would like to avoid this step.
Thank you.
.NET looks for managed registration-free COM first in the GAC, then in the executable's folder. It uses the activation context to read activation metadata, but not to determine the location of the files themselves.
You can save the DLL in a sub Folder, let say DLLFolder\YourDll.dll, and in the manifest file of yourDll, write the filename like
<file name = "DLLFolder\YourDll.dll">
But you need to keep the manifest file (of the DLL) in the location where the EXE is saved.
I'd like to change the security attribute of a directory that InstallShield creates under the CSIDL_COMMON_APPDATA - can someone please advise on how to do that during the installation process?
It's a script-defined folder.
Thank you.
Under InstallShield 2008 it's
Installation Designer > Components > [somecomponent] > Destination Permissions
Note that the directory properties are attached to the component, while individual File permissions are set under the 'Files' node
This assumes you are letting InstallShield / Windows Installer handle directory creation. If you're creating the directory in a script then things start getting tricky if you need to ensure a clean uninstall.
I think I found the answer for this - on this page: http://www.installsite.org/pages/en/isp_os.htm there's an ntperm.zip archive which contains a script that seems to do what I need.
you can also just easily call Windows commands "CACLS.EXE" or "ICACLS.EXE" -both are easy command line tool, e.g.
icacls file /grant Administrator:(D,WDAC)
- Will grant the user Administrator Delete and Write DAC
permissions to file
I don't know whether a Installshield builtin function exists for that. The simple solution is to create a DLL that does the real work of manipulating the security attributes and call it once the directory is created.
Typically, one might want to change the access so that everyone is able to read/write to the whole directory or file(s) within it.