Overview:
I just have a quick question about the ability to remap keys for a single user in in the registry:
Resources used:
ASCII table used:
http://www.csee.umbc.edu/portal/help/theory/ascii.txt
https://superuser.com/questions/694465/remapping-a-keyboard-key-in-windows-8-1
Which pointed me towards: http://www.howtogeek.com/howto/windows-vista/disable-caps-lock-key-in-windows-vista/
Attempt:
That tutorial talked about making remapping keys at the machine level via:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
So I thought to myself what the hell I would just try the same thing under: HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Control\Keyboard Layout
Unfortunately and somewhat expected it did not work:
reg add "HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v "Scancode Map" /t REG_BINARY /f /d 00000000000000000400000012005b005b00A200A200120000000000
^^^ This was supposed to switch: ^^^
the recognized windows key to the control key
the recognized alt key to the windows key
the recognized control key to the alt key
I even killed explorer.exe via power-shell:
taskkill.exe -im explorer.exe /f | Out-Null; start explorer.exe
Questions:
Is what I am trying to to even possible for a single user?
If it is how would I accomplish this without third party software?
That registry key is used by the keyboard driver. It reads it when it starts up. So killing Explorer has no effect, you'll have to reboot to make changes effective. Use shutdown.exe -r. Restarting the driver without a reboot is not possible.
Do beware that hacking this key is fairly dangerous, you can lose control over the machine when you make a mistake. I recommend KeyTweak, it has let me put the Ctrl key where it belongs for the past 10 years.
If it was to work, it would hypothetically have been in the HKEY_CURRENT_USER\Keyboard Layout key in the Registry. However, in the section "Scan code mapper for keyboards" in "Keyboard and mouse class drivers", it is noted:
"The mappings stored in the registry work at system level and apply to all users. These mappings cannot be set to work differently depending on the current user."
so it seems impossible to do mapping this way per-user. (It is the keyboard driver that reads this setting and does the translation, not the session manager).
For people finding this from an Internet search.
Microsoft PowerToys includes a tool for remapping keys for a user.
Probably safer than directly editing the registry.
https://github.com/microsoft/PowerToys
Related
I came across this link : https://vmxp.wordpress.com/2014/10/29/stress-testing-an-esxi-host-with-windows-server-vms/
.Since I am not so good in powershell i turned the whole thing to a simple batch script:
:loop
start testlimit64 -d
timeout /t 15
taskkill /f /im "testlimit64.exe"
timeout /t 9
goto loop
Note that I got into SYSTEM ACCOUNT before doing that using PsExec. The system I am using is a VM under ESXi. But nothing is happening, even the vm is not crashing. My aim is to crash whole esxi server.
I have two VMs under the ESXi and I ran the above scripts in both of them.
Still no luck. Am I missing something?
Windows 2000 Feature Allows a Memory.dmp File to Be Generated with Keyboard
Q244139
The information in this article applies to:
Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server
IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.
SUMMARY
Microsoft Windows 2000 includes a feature that enables you to have the system stop responding and generate a Memory.dmp file (if configured to do so). The "Stop" screen that generates contains the following parameters:
*** STOP: 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000)
The end-user manually generated the crashdump.
MORE INFORMATION
WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT or Windows 2000, you should also update your Emergency Repair Disk (ERD).
This feature is disabled by default. To enable this feature, you must edit the registry as indicated below and restart the computer. After restarting the computer, you can generate a system to stop responding by holding down the right CTRL key and pressing the SCROLL LOCK key twice. Pressing left CTRL key does not generate the system to stop responding.
Please note that the steps below will not work on Legacy Free computers, i.e., those that use a USB keyboard. For those, you must attach a debugger.
Start Registry Editor (Regedt32.exe).
Locate the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
On the Edit menu, click Add Value, and then add the following registry value:
Value Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1
Quit Registry Editor.
Additional query words: blue screen force dump bluescreen crash memory.dmp
For USB keyboards a USB one was added in a later OS. This sets Left Ctrl + Space, Spece for both USB (kbdhid) and PS/2 (i8042) keyboards.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\crashdump]
"Dump1Keys"=dword:00000020
"Dump2Key"=dword:0000003D
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\crashdump]
"Dump1Keys"=dword:00000020
"Dump2Key"=dword:0000003D
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"CrashOnCtrlScroll"=-
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters]
"CrashOnCtrlScroll"=-
I have my application written in Delphi XE that works with PDF files. Applicaiton is Win32. On start I would like to ensure that there is my item in explorer context menu for PDF files. I would like to be able to specify whether it should be added for active user only or for all users (with UAC I will need to restart with Admin privileges but thats ok).
I started with How to associate a Delphi program with a file type, but only for the current user? and How to add item to windows explorer content menu in delphi? . I tested it with manual registry editing via regedit and it worked fine for "new" extensions. But for .pdf it is more complicated as it will be most probably already present in the registry.
On my PC the .pdf key is referencing AcroExch.Document . But adding shell/something subkey to the AcroExch.Document key is not working because it has CurVer subkey referencing to AcroExch.Document.7. However another PC with another verison of Acrobat had this names a little different. It is no problem for me to follow the CurVer reference but is that a correct approach? And what about situation where no PDF reader is installed, how should I name my keys so Acrobat won't overwrite them when installed?
But more pressing matter is in which root should I put my keys? How to associate a Delphi program with a file type, but only for the current user? is mentioning HKLM (Local Machine) and HKCU (Current user). Its seems rather straightforward but I am unable to set values in HKLM from Delphi. Strangely I can create keys:
var reg:TRegistry;
key := '\Software\Classes\'+keyname+'\shell\'+name+'\command';
reg.CreateKey(key);
but I am getting Access Denied when trying to write the actual value:
reg.OpenKey(key,false);
reg.WriteString('',command);
I am getting the same Access Denied exception even on WinXP, no matter if the applicaiton is running as Admin (Win7), I even tried to set permissions (Everyone full control) for the key via regedit (I can edit the value via regedit without problems). I tried creating the registry with different access modes, all with no luck:
reg := TRegistry.Create(KEY_WRITE or KEY_WOW64_64KEY);
reg := TRegistry.Create(KEY_ALL_ACCESS or KEY_WOW64_64KEY);
reg.Access := KEY_ALL_ACCESS;
reg.Access := KEY_WRITE or KEY_WOW64_64KEY;
reg.Access := KEY_ALL_ACCESS or KEY_WOW64_64KEY;
With HKCU everything works fine.
So I tried writing into HKEY_CLASSES_ROOT and it works and actually puts the keys exactly where I want (into HKLM) if running as Admin. But according to http://msdn.microsoft.com/en-us/library/windows/desktop/ms724475.aspx
The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.
I do not like the note about the primary purpose being compatibile with 16-bit Windows. And the actual conditions where the changes will be written is more complicated than I would like.
So basically I have these questions:
What is the advantage of using AcroExch.Document and CurVer instead of pointing directly to AcroExch.Document.7? And what are the "best manners" when adding my keys into this structure? What about the case when the .pdf is not yet associated with anything?
Where should I put my keys and why I am not able to write into HKLM?
Edit:
The problem with Access Denied when writing to HKLM was caused by my error. I did use in previous code openKeyReadOnly and I did not notice that it will swtich the Access property to readonly for all subsequent calls.
To answer your other question, if Adobe is not installed yet then obviously the PDF keys will likely not exist in the Registry yet so you would have to create your own .pdf and ProgID keys so that you can attach your Shell command on it. If Adobe is installed afterwards, it is likely going to wipe out your keys and replace them with its own, so you would have to recreate your Shell command within Adobe's key structure. Your app can query the Registry to check for that condition periodically, such as at startup.
You have asked two separate questions. Since I know the answer to one and not the other, I'm going to answer just one. For future reference, I do recommend that you ask a single question at a time.
Where should I put my keys?
You are correct in discerning that you should not use HKCR. The documentation for HKCR says:
Class registration and file name extension information is stored under
both the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys. The
HKEY_LOCAL_MACHINE\Software\Classes key contains default settings that
can apply to all users on the local computer. The
HKEY_CURRENT_USER\Software\Classes key contains settings that apply
only to the interactive user. The HKEY_CLASSES_ROOT key provides a
view of the registry that merges the information from these two
sources. HKEY_CLASSES_ROOT also provides this merged view for
applications designed for previous versions of Windows.
....
If you write keys to a key under HKEY_CLASSES_ROOT, the system stores
the information under HKEY_LOCAL_MACHINE\Software\Classes. If you
write values to a key under HKEY_CLASSES_ROOT, and the key already
exists under HKEY_CURRENT_USER\Software\Classes, the system will store
the information there instead of under
HKEY_LOCAL_MACHINE\Software\Classes.
So, it is reasonable to use HKCR for reading, but for writing you typically need to exert control over whether to write to HKLM or HKCU. And that means that you cannot write to HKCR.
So, write to HKLM\Software\Classes for machine-wide settings, and HKCU\Software\Classes for user-specific settings.
Note that in Windows 7 and later neither of these keys is redirected and so you do not need to worry about using KEY_WOW64_64KEY. However, in Vista and XP64, and the equivalent server editions, these keys are redirected and reflected. Which means that it might be prudent to use KEY_WOW64_64KEY.
A nearly identical question was asked before. A good explanation of code pages was given in the reply, but it did not answer the question in my mind: What controls the code page used when cmd.exe is started? On my system, it gets changed somehow. In the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage, there is an item OEMCP that is set to 437. This seems to be the CP used by cmd.exe (as shown by chcp) after a fresh reboot, but something changes it later and it becomes 1252 in new cmd.exe windows. If I change it with chcp to 437, that only affects the current cmd.exe. When I exit and restart cmd.exe, chcp shows 1252 in the new window. What controls the default CP used when cmd.exe is started? How does it get changed from the value in the registry? How do I keep it from getting changed and/or change it back to 437 for new command windows?
The default code page in cmd.exe on my Windows syxtem is 437, which is the default OEM code page for most PC hardware sold in the United States (US) and Western Europe from what I've read. You can change this default by adding a string entry named AutoRun under one or both of the keys:
HKEY_CURRENT_USER\Software\Microsoft\Command Processor
and
HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor
in the Windows registry, as documented on this MS Windows Server 2003 support page. It describes how you can add a REG_SZstring entry named AutoRun under one or both of these keys with a value containing commands you want run automatically when cmd.exe starts up.
For example, to make code page 1252 the default, create a new string value named AutoRun after navigating to one of these keys in the regedit.exe utility program and then set its value to the command chcp 1252 afterwards.
Although the MS article only indicates it applies to Windows Server 2003, the technique also worked on the Win XP system I tested it on, so will probably also work with Vista & Win 7.
If Win+R and running cmd.exe /D fixes it then the problem is in the cmd autorun value...
I am referring specifically to windows 7.
I have code that associates a certain extension with my application as proposed by webJose on the following page:
What registry keys are responsible for file extension association?
(However i correctly write to HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT as suggested)
The above works initially, or if there are no other programs associated with the extension. However after using the Windows 7 built-in "Choose default program..." (found under the file-right-click context menu under "Open with") it re-associates the extension with whatever new program you choose.
What happens at this point is that "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\\UserChoice" is changed by the system, and so the newly selected program takes over.
Running the above code, to regain control over the extension will not work. The only way to regain control, is by either:
Editing the UserChoice -> Progid value, which is not allowed (neither programmatically nor using regedit.exe - access denied).
Or deleting the UserChoice value and making sure your application is the first in the MRUList value under \OpenWithList (this can be achieved using regedit.exe but not programmatically)
My question is: Is there a way to achieve this programmatically? What registry values can be changed to regain control of an extension, after is associated with another program?
I know it might seem obvious that if a user through explorer sets the associated application to an extension, that it would be expected to do it the same way again to re-associate the extension to a different application.
The problem however is I have a button in my application that uses the above mentioned code to check for extension association with my application. Unfortunately with the above situation, my application displays a message confirming that the extension is already successfully associated when its not! So is there a way around this?
Deleting UserChoice should revert the default program to the standard file association keys (which starts with the ProgID in HKCU). Barring that you could also delete OpenWithList, which would be reverting with extreme prejudice.
Edit:
Check out Registry Key Security and Access Rights on MSDN, particularly the RegSetKeySecurity function. Remember that you'll need to grant yourself administrative control to the key before you can delete it.
Well regarding file assoc in Window 7 a new 'problem' araised.
It's one of this: You've to fight for your rights.
Assuming you like to run
REG.exe DELETE "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mov\UserChoice" /f /va
You'll get ACCESS DENYED.
When you check security setting of the key in Regedit 'UserChoice' you'll see that there's a setting windows made for you, to deny 'set' for the current user. Well you maybe change/delete this setting in regedit and now you can delete UserChoice.
However for programmer/scripters that setting is a little bitchy since there are now real tools to set ACLs in the registry. However here some workaround that at allows to delete keys with ACCESS DENYED (of course this only works incase you've the right to change permissions):
ResetMovAssoc.cmd
::create 'empty.hiv'
REG ADD "HKCU\emptyKey" /f
REG SAVE "HKCU\emptyKey" empty.hiv /y
#REG DELETE "HKCU\emptyKey" /f >nul
::^-note you can add #[...] >nul to the other entries as well to run them quite
:: Delete Reg key by replacing it with an empty hiv
REG RESTORE "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.mov" empty.hiv
del empty.hiv
To summarize this the major thing here is REG RESTORE + Registry hive file containing just and empty key.
In Regedit that'll equivalent to Import' with a just an empty registry structure file (Note: that's a hive file and not a *.reg file).
My solution was not to try to delete the UserChoice key (only administrators can do it), but to delete the key the ProgId is pointing to. If the user made a choice in the past the ProgId has a value like Applications\*.exe. The non-admin can delete the key in a batch:
REG DELETE HKCR\Applications\*.exe /f
This might be a bit of a hack, but worked for me.
Also on Windows 10, this command can't work:
Reg.exe delete "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.m4v" /f
The solution is to delete the SID key by running a BAT file under TrustedInstaller (with NSudo, PowerRun, etc):
for /f "delims=\ tokens=2" %%A in ('reg query hku ^| findstr /i "S-1-5-21-" ^| findstr /v /i "_Classes"') do set SID=%%A
Reg.exe delete "HKU\%SID%\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.m4v" /f
P.S.: Thanks to #SecurityAndPrivacyGuru for sharing the SID detection command.
If you want to open an msg Email file with the extension .msg, Outlook 2003 will be started with some parameters. Therefore you can find the following registry keys:
HKEY_CLASSES_ROOT\msgfile\shell\Open\command\(standard)
HKEY_CLASSES_ROOT\msgfile\shell\Open\command\command
The first one points to the "outlook.exe" with the parameter /f "%1". This starts Outlook with the information to open the mail.
But the "command" key has the following value:
%]gAVn-}f(ZXfeAR6.jiOUTLOOKFiles>ir#X7cr$%#u$}&V7{4p' /f "%1"
Can anybody tell me what exactly this is good for?
I'm writing an vsto Outlook Addin for which I need to modify these keys. In case I modify the "standard" key, Outlook will be started normaly without using my alteration of the key. If I also modify the "command" key Outlook does not even start anymore.
Only if I delete the "command" key everything works fine as expected. But without knowing what the key is good for, this cannot be a solution.
this "command" value is a so-called "Darwin Descriptor" generated by Windows Installer to automatically repair a broken installation.
See http://www.symantec.com/community/tip/4999/darwin-descriptor or google for "MSI darwin descriptor".