I have an x64-platform application running on Windows 8.1, x64...it crashes from time to time (its a multibyte, COM+ object hosted in a Windows service). I wanted to get the OS to write mini-dump files whenever an exception happens, so I set the following keys up in my registry:
Yet when a crash does occur, I see nothing in %LOCALAPPDATA%\CrashDumps. Why is this happening? Is it because the service is running under the Local System account?
As it turns out, the dumps were being created. They were being created in C:\Windows\System32\%LOCALAPPDATA%\CrashDumps. This is because %LOCALAPPDATA% maps contextually under the context of a user account. If you use the Local System account for a service, this doesn't translate to anything...so it just appends to the default path of Local System which is C:\Windows\System32. Kind of a funny way to handle this case, M$...
Related
I have a 32-bit program that is trying to access a key stored in HKLM\Software\Microsoft\VisualStudio in a Windows 64-bit setup running Windows 8.1.
Usually it works just fine and it will actually read that key from the Software\Wow6432Node.
However I have one machine (which doesn't seem that different from others) for which the read fails. When I look at the registry accesses with Process Monitor it shows that it is trying to read it from the VirtualStore and there it is not present, thus the failure.
Any reason why Windows is not presenting the merged view to my application as it does on other installs?
Thanks,
Manu
The virtual store is a compatibility mechanism that was introduced with UAC, and is not directly related to WOW64. When a program that does not declare itself to be compatible with Windows Vista attempts to create a key or file but does not have access to do so, Windows redirects the write into the virtual store. From that point onwards, attempts to open that key or file will be automatically redirected to the virtual store.
To avoid being redirected to a virtual store key or file that another application may have created, use a manifest to declare that your application is compatible with Windows Vista.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
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.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
I am running my application (sample.exe) which uses an external DLL (i.e. I do not have the source of this DLL) on windows. External DLL generates some data in the %appdata% folder. Everything runs fine when the application is run standalone.
Now, when I run the sample.exe using MPI the logs are getting generated in "C:\Windows\System32\config\systemprofile\AppData"
I understand that this is the %appdata% for SYSTEM. Also, MPI uses "smpd" service to run which needs to be installed as Administrator. So, I thought probably the sample.exe is owned by the system and not by the user. But, when checked from the task manager the owner of the application is still the user(%username%).
I dont understand why are the logs generated in the system's appdata folder rather than the user's appdata folder.
Since sample.exe is your own application, you can troubleshoot the problem by adding logging code. For example:
Call SHGetKnownFolderPath to determine the application data folder.
Call GetUserName to check what user account you are running under.
Call GetEnvironmentStrings to determine how the environment variables are set, paying particular attention to %APPDATA% and %LOCALAPPDATA%.
If this is a C program, use getenv("APPDATA") and getenv("LOCALAPPDATA") as well; IIRC, the C runtime library keeps it's own copy of the environment variables.
If the application data folder is correct but the environment variable isn't (this would be my first guess as to the problem) then you can try using SetEnvironmentVariable and/or _putenv to correct the path before loading the external library.
The likely explanation is that a service running under the LOCALSYSTEM account is saving the file. Knowing very little about the architecture of your application, I can't say in any detail how this comes about.
This is because your Windows service is running with "Local System Account". Go to the properties of your service and the "LogOn" tab. Change from Local System Account to "This account" and give your credentials. NO, the service should run in User account and should use the user AppData.
I need to migrate a huge application to Windows Azure. The application uses SHGetSpecialFolderLocation() and related WinAPI functions to obtain path to "special folders" like %PUBLIC% ("c:\Users\Public\" by default on Windows 2008) and later stores stuff in that folder.
Can such special folders be accessed on Windows Azure?
You can definitely use the API and it will work just like normal Windows. The API is not the issue, but rather what you do with it that could be an issue. Unless you have a startup task or some other way to persist any changes that you write to these locations, they will be lost at the next service healing. For instance, if you asked for %SYSTEMROOT%, you would get "D:\Windows" in Windows Azure. That is great except when you go ahead and write a file you expect to persist into this location. The same thing goes to changes to the registry. The only way you can depend on these changes is to do it within a Startup task or some other mechanism to make sure that even after a service healing you would be back in the same state.
My application consists of two parts: A Windows Service running under the LocalSystem account and a client process running under the currently logged in regular user.
I need to deploy the application across Windows versions from XP up to Win7.
The client will retrieve files from the web and collect user data from the user.
The service will construct files and data of it's own which the client needs to read.
I'm trying to figure out the best place (registry or filesystem, or mix) to store all this. One file the client or service needs to be able to retrieve from the net is an update_patch executable which needs to run whenever an upgrade is available.
I need to be sure the initial installer SETUP.EXE, and also the update_patch can figure out this ideal location and set a RegKey to be read later by both client and server telling them the magic location (The SETUP.EXE will run with elevated privileges since it needs to install the service)
On my Win7 test system the service %APPDATA% points to:
C:\Windows\system32\config\systemprofile\AppData\Roaming
and the %APPDATA% of the client points to:
C:\Users\(username)\AppData\Roaming
Interestingly Google Chrome stores everything (App and Data) in
C:\Users\(username)\AppData\Local\Google\Chrome
Chrome runs pretty much in exactly the way I want my suite to run (able to silently update itself in the background)
What I'm trying to avoid is nasty popups warning the user that the app wants to modify the system, and I want to avoid problems when VirtualStore doesn't exist because the user is running XP/2000/2003 or has UAC turned off.
My target audience are non-tech-savvy general Windows users.
Chrome doesn't have any services running under the LocalSystem account, though.
If you want to have files that can be shared between accounts on the same system, store them under the %ALLUSERSPROFILE% folder.
If you just want to be able to auto-update programs, then doing what Chrome does is fine: just make sure you launch the updated elevated when UAC is turned on.