I set up the registry key, HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps as described on MSDN.
I have a test program - a console program, compiled with Visual C++, that tries to dereference a NULL pointer before printing a message and exiting. The test program used to exit and dump a core file, but now it just exits. I get no core.
I'm running Windows Server 2008 R2 Enterprise, SP1 on physical hardware.
I don't know what changed. What could have changed that prevents WER from dumping cores now?
The following may go wrong:
Permissions of the folder to write to
Looking at the permissions of the folder C:\ProgramData\Microsoft\Windows\WER it has
Read & execute
List folder contents
Read
Creating a subfolder LocalDumps will inherit the permissions.
So you should either modify the permissions of that folder or use a different folder with write permissions.
Permissions of the Registry key
Windows might not be able to read the Registry settings if the permissions do not allow it. E.g. the following (really silly) permissions will prevent a LocalDump as well:
32 vs. 64 bit
Windows Error Reporting is executed by Windows and only uses the registry key with the bitness of the OS. You said you set up both. If that's true, it`s fine. If you only set up the 32 bit Registry key, it won't work.
AeDebug
If you have a setting for AeDebug HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug, those are executed before WER.
Note that this entry may exist in 32 bit (WOW6432Node) and 64 bit.
Usually that should result in starting a debugger, but who knows ... it might do nothing and just exit.
LocalDumps is disabled
Make sure that there is no DWORD Disabled with a value of 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Use of REG_SZ instead of REG_EXPAND_SZ
I have seen people using a REG_SZ for DumpFolder in combination with %APPDATA%. Only REG_EXPAND_SZ will expand environment variables.
Make sure you've added a key on the LocalDumps node like "LocalDumps\MyApplication.exe". Then, update the values that are explained in that link. At the time of a crash, WER looks for a key with the matching application name to decide how to handle the dump.
Related
The user mode dump collection feature in Windows is well documented. As long as the LocalDumps key under HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting is created, every application crash on the system produces a core dump using the default setting. A subkey under it, named after the executable file for the process I am interested in, is overriding the global (default) setting, and I am getting the crash dumps just nominally, full memory burp in the location I specify.
However, there is apparently no setting in the documentation under the LocalDumps that would tell the system not to create dumps, such that I would override one for my service's subkey. In our milieu, there are multiple service processes running under multiple identities, so there are going to be many core dumps scattered around all there identities' %LOCALAPPDATA%\CrashDumps directories, needlessly. These are unattended servers, and more trash means more scripted cleanup.
Is there a documented way to disable core dumps by default for all programs, and override the prohibition for just one?
It is documented that dumps are not created if the location is not writable by the crashing process' identity, but I do not want them for LocalSystem services too, and this guy can write anywhere. Also, it seems that the dumps are not created if the DumpFolder points to an invalid filepath. To make it even maybe a little less hacky, I set it to the NUL device in the device namespace (: stands for "value under key" below):
LocalDumps:DumpFolder=\\.\NUL
LocalDumps:DumpCount=1
LocalDumps\myservice.exe:DumpFolder=C:\Program Files\myservice\data\crash_dumps
LocalDumps\myservice.exe:DumpType=2
LocalDumps\myservice.exe:DumpCount=5
This ostensibly works in Server 2012, 2012R2 and 2016. But I must keep fingers crossed that a next update would not change this (undocumented) behavior.
I have a batch file that copies a directory to a new location, creates 2 other .bat files, 2 .json files, and Inserts Registry Keys. When running the batch script for the command line, I get no errors and all desired outcomes. While running it from the post-build event command-line, I get no errors, but I'm missing the Registry entries. Co-worker suggested that this could be due to Visual Studio not having Admin permissions whereas the command line can. My question is: is there a way (without running Visual Studio as an admin) to elevate permissions for a post-build event? If you're wondering why not just run VS as admin, it's because this solution is shared via TFS, and not all my co-workers will know to run their instance of VS as admin for this one particular solution. I've Googled away with nothing to show for it. Thanks in advance for help! Here's the Post-build event command line I'm using. Again I know it works... it just doesn't plop the Registry values. CMD does. PS. Using VS 2013 on Windows 7
if $(ConfigurationName) == Debug call "$(ProjectDir)BatchFiles\DebugHelper.bat" "$(TargetDir)" C:\CEC\Batch\Test\
This is from Windows SDK about redirection (there is also reflected and shared)
Registry Redirector
The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of key portions of the registry on WOW64. The registry redirector intercepts 32-bit registry calls to each logical registry view and maps them to the corresponding physical registry location. The redirection process is transparent to the application. Therefore, a 32-bit application can access registry data as if it were running on 32-bit Windows even if the data is stored in a different location on 64-bit Windows.
Redirection is enabled for the following registry keys:
HKEY_LOCAL_MACHINE\Software
HKEY_USERS\*\Software\Classes
HKEY_USERS\*_Classes
Note * indicates a match for all user security IDs (SID).
The following scenario illustrates the use of these logical views:
A 32-bit application checks for the existance of the following registry key: HKEY_LOCAL_MACHINE\Software\Hello. If the key does not exist, it creates it with a default value of "Hello 32-bit world"; otherwise, it reads and displays the value.
The same application is modified to write "Hello 64-bit world" instead of "Hello 32-bit world" and recompiled as a 64-bit application.
When the 32-bit application is run on 64-bit Windows, it displays "Hello 32-bit world". When the 64-bit application is run, it displays "Hello 64-bit world". Both applications call the same registry functions with the same predefined handle and the same key name; the difference is that each application operates on its logical view of registry, and each view is mapped to a separate physical location of the registry, which keeps both versions of the string intact.
To help applications that write REG_EXPAND_SZ keys containing %ProgramFiles% to the registry, WOW64 intercepts these writes and replaces them with "%ProgramFiles(x86)%". This environment variable is defined for all processes. For example, if the Program Files directory is on the C drive, then "%ProgramFiles(x86)%" expands to "C:\Program Files (x86)".
To enable application interoperability through COM and other mechanisms, WOW64 uses registry reflection, which copies specific registry keys and values between the two registry views to keep them in synch. The reflector is intelligent and copies COM activation data for Local servers between the views, but not in-process data, because 32/64 in-process data mixing is not permitted on 64-bit Windows.
What to do
In a program
KEY_WOW64_64KEY 0x0100 Access a 64-bit key from either a 32-bit or 64-bit application.
Windows 2000: This flag is not supported.
KEY_WOW64_32KEY 0x0200 Access a 32-bit key from either a 32-bit or 64-bit application.
Windows 2000: This flag is not supported.
From command prompt see reg flags /? allowing your key to opt out of redirection.
And a reminder that UAC also may be virtualising it. As it redirects some writes to HKLM to HKCU. Giving permission for users to write to your key will overcome that.
Forgive me if the title is not so accurate.
I have met some problem when I am doing something related to COM server and registry redirection and not quite sure is my understanding is correct or not. Hoping anyone could share some light on it. Thanks in advance.
Basically a COM server has been registered in the registry before anyone can use its service. On a 64bit Windows OS, there could be 2 possible views in the registry table, one is for default and the other for the WOW64 view. For example, first registry key is: COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{GUID}\LocalServer32 and the other is: COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{GUID}\LocalServer32.
And depends on the process bitness (64bit vs. 32bit) that either one can be read by default, and also we can use KEY_WOW64_64KEY or KEY_WOW64_32KEY (as: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384129(v=vs.85).aspx) to access the other alternative registry key.
What I need is that, I want to get the LocalServer32 executable file by reading the registry key and this can work. The problem is that, for the executable file path I read back, do I need to do the file path translation (in order to get the correct value) depending on which view I get the value from? For example, if the file path is got from COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{GUID}\LocalServer32 and the file path is: C:\Windows\System32\abc.exe, do I need to translate the path to: C:\Windows\SysWow64\abc.exe? Or do I need to translate C:\Program Files\abc.exe to C:\Program Files(x86).exe?
Another question is that, if, for some registry key for COM, the values set in the two Views are different (for example, one has C:\Program Files\abc.exe and the other has C:\Program Files(x86)\abc.exe), then when the COM server is started, how could svchost.exe know which one to start, C:\Program Files\abc.exe or C:\Program Files(x86)\abc.exe? Does anyone know the logic for svchost.exe to determine this? Use the first one if it exists otherwise use the second one?
Thanks a lot.
A 64-bit version of Windows already has all the features in place to make it unnecessary for you to take care of it yourself. You just need to keep the rules in mind when you troubleshoot problems.
First is the registry redirector, it ensures that a 32-bit client program cannot accidentally read keys that contain configuration information that's only appropriate for 64-bit programs. You already know it, most of the HKLM\Software registry accesses are redirected to HKLM\Software\Wow6432Node. This redirection is already in place when the COM server is registered, a 32-bit installer is automatically redirected to write the keys to Wow6432Node instead. The installer is completely unaware that Wow6432Node even exists. Everything falls together automatically, the installer is redirected and the COM server client is redirected as well. All that you care about is knowing where to look to verify that the install was done properly, you do have to look at HKLM\Software\Wow6432Node\Classes\CLSID with Regedit.exe to find the keys back.
File redirection works much the same way, any access to c:\windows\system32 is redirected to c:\windows\syswow64, from c:\program files to c:\program files (x86). And very similarly, a 32-bit installer doesn't have to know beans about this, it can simply use the legacy 32-bit path names. Same for any 32-bit client program, it will be redirected the same way. All that you care about is knowing where to look for a file to verify the installer.
This can only go wrong if bitness is mixed, a 64-bit program reading registry keys or files installed by a 32-bit program. Or the other way around. Like it does with your troubleshooting tools, like Explorer, Regedit and SysInternals' Process Monitor. In general something that should be strongly avoided in COM, most servers are in-process servers and running 32-bit code in a 64-bit process is not possible. The biggest reason that the registry and file redirectors exist in the first place.
I am using REG QUERY HKLM/SOFTWARE command to retrieve all installed soft wares,
but its not returning few of applications, what ever the application I needed is a 64 bit one.
OS:- Windows 7
Note:- When I use the command its returning the applications which are under [Wow6432Node] folder, but my application is not presented under this folder. Its present under [HKLM/SOFTWARE] location
Please help me to solve this problem.
This behaviour is due to the registry redirector. You are running the 32 bit version of REG, presumably because the process that invokes it is a 32 bit process. And so the 32 bit version of REG reads the 32 bit view of the registry by default.
You should use /reg:64 switch to force reg to use the 64 bit view of the registry, as described here: MS-KB-948698.
If you are doing this from a program then it's better to use the registry API to read entries than using the REG tool.
I have a 32-bit application and a 32-bit installer, written in Wise Installation Studio. I know...I shouldn't be using Wise and I should switch to something else. But for now, I'm stuck with it.
Our application is graphics-intensive and to improve performance, we want it to disable desktop composition (Windows Aero) while running. We accomplished this on 32-bit systems by adding a registry entry at:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
with a value of DISABLEDWM.
This sets the "Disable desktop composition" checkbox in the compatibility tab of the properties for our EXE to be checked by default.
This works perfectly on 32-bit systems, but when running the installer on a 64-bit system, Windows redirects the creation of registry entries to HKLM\SOFTWARE\Wow6432Node, and the flag is not set correctly. If I manually create an entry in the 64-bit registry view, then it works.
So how can I force this registry key to be created in the 64-bit registry view from our 32-bit installer? Or is there a better way to set this property aside from creating a registry entry?
I'm not sure what possibilities Wise gives you regarding scripting, but the way to access the 64-bit registry from a regular program is to use KEY_WOW64_64KEY when manipulating the registry.
If it's a possibility to at the least run an external EXE file from the setup, it should solve your problem.
I am not sure if this solution was possible at the time this question was asked, but you can create a custom action that executes a REG ADD command and include the /reg:64 switch, like this:
REG ADD "HKLM\Software\Example" /v "Name" /t REG_SZ /d "Data" /reg:64
The /reg:64 switch will force it to the 64-bit registry. I am not entirely sure what this will do on a 32-bit system, but I expect it will probably be ignored.
Usually you can not access the 64 bit registry from 32 bit applications. I have found some code, which is for PowerShell, that allows you to access the 64 bit registry through WMI: http://gallery.technet.microsoft.com/scriptcenter/6062bbfc-53bf-4f92-994d-08f18c8324c0
However, I'm not sure whether you can use this in Wise. You could use Windows Installer XML instead and have it create a 64-bit MSI.
I also use Wise and have to support both 32 and 64 bit windows. I have had some success using batch files to call reg.exe to delete and query 64 bit registry entries. You should be able to employ the same technique to add and modify the registry. I look for "program files(x86) to determine if it is 64 bit windows. If not, I use the native registry controls in wise, otherwise, I use the batch files with passed in parameters. Reg.exe should be in your path. go to a dos prompt and type reg /? to get the syntax.
I have a regtest.bat, which contains the following:
reg.exe query %1 /v %2 > %3
The first param is the registry key, second is the value, and third is the text file it is written to.
My regdelete.bat contains:
reg.exe delete %1 /f The param is the registry entry you want to delete.
The problem still exists although query registry with Reg.exe
Because when the bat file called by Wise, the reg query can not find 64 bit key(only 32 bit key can be found).
You could also use
c:\Windows\SysNative\REG.exe ADD "HKLM\Software\Example" /v "Name" /t REG_SZ /d "Data"
This forces the use of the 64-bit version of reg.exe. Of course, that's not going to work if you're on a 32-bit OS. So you should put in a check for the OS type, and then call the proper reg.exe program (either c:\Windows\System32 for 32-bit OS, or C:\Windows\SysNative for 64-bit OS).
The environment variable PROCESSOR_ARCHITEW6432 will have the value of AMD64 if it's a 64-bit OS, and empty if 32-bit OS.