I have a problem with RegOpenKeyEx() function.
lResult = RegOpenKeyEx(HKEY_LOCAL_MACHINE, lpSubKeyName, 0, KEY_READ, &hkMon);
Function return error code 2 (file not found), but this key exist in registry.
I try this on Windows 7 64-bit and Windows Xp 32bit.
When working with the registry you have to be aware of UAC registry virtualization (VirtualStore redirection for compatibility) and WOW64 (32/64 bit separation and registry redirection/reflection). Because of these features you sometimes end up in a different place in the registry and it will not match up with what you see in Regedit.
In cases like these the best thing to do is to use Process Monitor so you can see which key you are really accessing...
Related
I have a 32 bit program which is running in two lanes in the same store. The program tries top open a registry key for query. The operating system is Windows 8.1 64 bit.
On one lane it succeeds, and on the other it fails and regopenkeyex returns 2. GetLastError returns 0.
The key it tries to open is under WOW6432Node.
The program is running under the same Windows user on both machines, the key exists on both. the UAC is set to "Never notify" (lowest), windows version is the same. Everything is supposed to be the same...
I am deliberately not specifying KEY_WOW64_64KEY because the code is supposed to work without it. But even when I do use it I get the same result.
What could be causing this?
The code:
rc = ::RegOpenKeyEx(HKEY_LOCAL_MACHINE,
szKey,
0,
KEY_QUERY_VALUE,
&m_hKey);
Thank you.
You actually need to read about the functions you are using on MSDN. The registry functions return the error code directly, they do not use GetLastError!
2 is ERROR_FILE_NOT_FOUND so whatever you are hiding in szKey is not a valid subkey path.
WOW6432Node is a reserved key name that you really should not be using, use KEY_WOW64_32KEY if you need to access the 32-bit registry view in a 64-bit application. A 32-bit application reads keys under the WOW6432Node key by default.
Use Process Monitor to make sure you are accessing the correct key.
I am trying to display a new Word document inside a Widget, using OLE. This works fine as long as I compile my application under x86 architecture. Now I tried porting my application to x64 and it stopped working. The call to OleCreate() fails with REGDB_E_CLASSNOTREG.
CLSID clsID;
IUnknown* pIUnknown;
HRESULT res = CLSIDFromProgID(L"Word.Document.8", &clsID);
if (SUCCEEDED(res)) {
res = OleCreate(clsID, IID_IUnknown, OLERENDER_DRAW, NULL, NULL, storage, reinterpret_cast<void**>(&pIUnknown));
}
After some research I came across some solutions, but none of them were applicable.
I can't set my compiler to x86 when I'm trying to port my application to x64 so following Post hasn't solved my problem.
I tried calling regsvr32.exe withC:\Windows\System32\ole32.dll but it didn't change the result.
I tried installing the hotpatch, which was shipped by microsoft to fix the same problem with OleCreateFromFile(). Sadly it doesn't fix the problem for OleCreate() - hotfix
The only solution, which worked so far was to copy the content of HKLM\SOFTWARE\SysWow64\Classes\CLSID\<CLSID of Word Document> into HKLM\SOFTWARE\Classes\CLSID\<CLSID of Word Document> but this is more of a hack than a fix, because I would have to modify the registry of every machine on which I want to run my application. Since this task requires administrator privileges, I can't do this from inside my application.
I need a solution which works and doesn't force me to manually alter registry entries.
I'm running my application on a Windows 7 Professional SP1 64-Bit machine with a 32-Bit Office 2010.
After some more testing I found the solution to the problem, which was to use Word.Document instead of Word.Document.8 as progID.
I have don't know why this seems to be a problem with 64-Bit compilation. The thing, I noticed though was that CLSIDFromProgID() now resolves to a different CLSID.
I have a problem with the registry in Windows x64. I need to get a value added through file.reg:
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\My Soft]
"Str1" = "Assa"
"Str2" = "142Z5214GGAAVGA"
In the code, I do:
RegCreateKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\My Soft", 0,NULL,0, KEY_READ | KEY_WOW64_64KEY,NULL,&hKey,&dwDis))
/*
Get the value by RegQueryValueEx...
*/
In a 32-bit Windows is good. In a 64-bit value is empty.
PS:
Sorry for my English by Google Translate ^_^
You say you need to get a value, but you're calling RegCreateKeyEx. Do you actually need to create it? If so, it's probably created in HKLM/Software/Wow6432Node.
Have you tried HKEY_LOCAL_MACHINE\Software\WOW6432Node ?
The default 64-bit version of Registry Editor (Regedit.exe) that is included with 64-bit versions of Windows displays both 64-bit keys and 32-bit keys. The WOW64 registry redirector presents 32-bit programs with different keys for 32-bit program registry entries. In the 64-bit version of Registry Editor, 32-bit keys are displayed under the following registry key.
Source
I have a dll made in cpp which tries to read/write some Registry Keys. This code runs perfectly fine in Windows XP (32 bit environment) but it fails in Windows 7(64 bit environment).
The registry keys which this application accesses is the shared registry keys. These keys are not part of 32 bit registry cache(wow32 bit) or 64 bit registry cache.
Please provide your valuable inputs on this.
Thanks in advance.
Jits
when you say "shared" you mean for example under HKLM? Only elevated applications are allowed to write to those on Windows 7 and Vista. If this is news to you I suggest searching on User Account Control or UAC.
Check out this: RegQueryValueEx Function
And this: Registry Key Security and Access Rights
IMO you have to check your permission settings that you use to open the key. Either remove the settings that require elevated privileges or run your app in elevated mode.
Maybe you should initialize the value of "lpcbData", the last parameter of RegQueryValueEx.
In attempting to upgrade some C++ software to run in Windows 7 I have experienced some problems in being able to create registry keys from scratch.
This is my code:
//
// Create a brand new registry key
//
LONG Registry::CreateRegister( std::string path )
{
HKEY hKey;
DWORD dwDisposition;
LONG openRes = RegCreateKeyEx( HKEY_CLASSES_ROOT,
path.c_str(),
0,
NULL,
REG_OPTION_NON_VOLATILE,
KEY_ALL_ACCESS,
NULL,
&hKey,
&dwDisposition );
RegCloseKey( hKey );
return openRes;
}
In Windows XP, the RegCreateKeyEx function successfully creates the registry key, returning a success (0) value. In Windows 7 I am getting a return value of 5 (access denied) from the same function.
I used the regedit tool to ensure that my account has the necessary full permissions, but without success. Can anyone see where I might be going wrong, or if there are other gotchas and known issues I need to be aware of when using Visual Studio within Windows 7?
The software is currently written in Visual Studio 2003.
Thanks in anticipation.
Since Vista, access to certain areas of the registry has been locked down. The user must have "elevated" permissions. Try running your program with "Run as administrator" (right click it in Explorer).
See Registry Key Security and Access Rights and
RegCreateKeyEx
For parameter "hKey [in] A handle to an open registry key. The calling process must have KEY_CREATE_SUB_KEY access to the key."
This tuto help you Teach Your Apps To Play Nicely With Windows Vista User Account Control
and The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)