[Bug 50296] New: Multiple 32-bit applications fail due to incorrect handling of 'HKLM\\Software\\Classes' key in 64-bit WINEPREFIX (shared key under Windows 7+ WOW64)(Autocad 2005)
WineHQ Bugzilla
wine-bugs at winehq.org
Wed Dec 9 10:26:44 CST 2020
https://bugs.winehq.org/show_bug.cgi?id=50296
Bug ID: 50296
Summary: Multiple 32-bit applications fail due to incorrect
handling of 'HKLM\\Software\\Classes' key in 64-bit
WINEPREFIX (shared key under Windows 7+ WOW64)(Autocad
2005)
Product: Wine
Version: 6.0-rc1
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wineserver
Assignee: wine-bugs at winehq.org
Reporter: focht at gmx.net
Distribution: ---
Hello folks,
as it says. I'm pretty sure there are already a number of existing bugs with
the same root cause.
Affected app here: Autocad 2005
Registration fails after installation in 64-bit WINEPREFIX with endless
urlmon/ieframe looping.
Installer and app are both 32-bit.
--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files (x86)/AutoCAD 2005
$ file acad.exe
acad.exe: PE32 executable (GUI) Intel 80386, for MS Windows
$ WINEDEBUG=+seh,+loaddll,+mshtml,+ieframe,+urlmon,+reg wine ./acad.exe
>>log.txt 2>&1
...
02f4:trace:ieframe:BindStatusCallback_OnProgress (053C4438)->(4760 4760 14
L"C:\\Program Files (x86)\\AutoCAD 2005\\Webdepot\\RTBeginReg.html")
02f4:trace:urlmon:BindStatusCallback_OnProgress 053C4A70)->(4760 4760
BINDSTATUS_ENDDOWNLOADDATA L"file://C:\\Program Files (x86)\\AutoCAD
2005\\Webdepot\\RTBeginReg.html?p=C%3A%5Cusers%5Cfocht%5CTemp%5C~RTf171.tmp%5C")
02f4:trace:ieframe:BindStatusCallback_OnProgress (053C4438)->(4760 4760 6
L"file://C:\\Program Files (x86)\\AutoCAD
2005\\Webdepot\\RTBeginReg.html?p=C%3A%5Cusers%5Cfocht%5CTemp%5C~RTf171.tmp%5C")
02f4:trace:ieframe:set_status_text (053C4438, 6, L"file://C:\\Program Files
(x86)\\AutoCAD
2005\\Webdepot\\RTBeginReg.html?p=C%3A%5Cusers%5Cfocht%5CTemp%5C~RTf171.tmp%5C")
02f4:trace:ieframe:set_status_text => L"Downloading file://C:\\Program Files
(x86)\\AutoCAD
2005\\Webdepot\\RTBeginReg.html?p=C%3A%5Cusers%5Cfocht%5CTemp%5C~RTf171.tmp%5C"
02f4:trace:urlmon:Binding_AddRef (053C5168) ref=6
02f4:trace:reg:NtOpenKeyEx (0x74,L"MIME\\Database\\Content
Type\\text/html",2000000,0x31a378)
02f4:trace:reg:NtOpenKeyEx <- (nil)
02f4:warn:urlmon:get_mime_clsid Could not open MIME key: 2
02f4:trace:urlmon:BindStatusCallback_OnProgress 053C4A70)->(0 0
BINDSTATUS_BEGINSYNCOPERATION (null))
02f4:trace:ieframe:BindStatusCallback_OnProgress (053C4438)->(0 0 15 (null))
02f4:fixme:urlmon:create_object Could not find object for MIME L"text/html"
02f4:trace:urlmon:BindStatusCallback_OnProgress 053C4A70)->(0 0
BINDSTATUS_ENDSYNCOPERATION (null))
02f4:trace:ieframe:BindStatusCallback_OnProgress (053C4438)->(0 0 16 (null))
02f4:trace:urlmon:BindStatusCallback_OnStopBinding (053C4A70)->(80040154
(null))
02f4:trace:ieframe:BindStatusCallback_OnStopBinding (053C4438)->(80040154
(null))
02f4:trace:ieframe:set_status_text (053C4438, 0, L"")
02f4:trace:ieframe:set_status_text => L""
02f4:trace:ieframe:notify_download_state (0)
02f4:trace:ieframe:WebBrowser_Invoke (001F6A78)->(104
{00000000-0000-0000-0000-000000000000} 0 00000001 00317F18 00000000 00317EF8
00317F38)
02f4:trace:ieframe:WebBrowser_Navigate (001F6A78)->(L"file://C:\\Program Files
(x86)\\AutoCAD
2005\\Webdepot\\RTConnectFail.html?p=C%3A%5Cusers%5Cfocht%5CTemp%5C%7ERTf171.tmp%5C"
(null) (null) (null) (null))
02f4:trace:ieframe:navigate_url navigating to L"file://C:\\Program Files
(x86)\\AutoCAD
2005\\Webdepot\\RTConnectFail.html?p=C%3A%5Cusers%5Cfocht%5CTemp%5C%7ERTf171.tmp%5C"
02f4:trace:ieframe:WebBrowser_AddRef (001F6A78) ref=6
02f4:fixme:ieframe:handle_navigation_error Navigate to error page
...
<repeats endlessly>
--- snip ---
Failure to open 'HKCR\\MIME\\Database\\Content Type\\text/html' seemed pretty
suspicious to me.
64-bit registry view:
--- snip ---
[HKEY_CLASSES_ROOT\MIME\Database\Content Type\text/html]
"CLSID"="{25336920-03F9-11CF-8FD0-00AA00686F13}"
"Encoding"=hex:08,00,00,00
"Extension"=".htm"
--- snip ---
Apparently 32-bit urlmon looks up the key in the redirected 32-bit view?
According to Microsoft docs:
https://docs.microsoft.com/en-us/windows/win32/winprog64/shared-registry-keys#redirected-shared-and-reflected-keys-under-wow64
--- quote ---
The following table lists registry keys that are redirected, shared by both
32-bit and 64-bit applications, or redirected and reflected on 64-bit Windows.
Subkeys of the keys in this table inherit the parent key's behavior unless
otherwise specified. If a key has no parent listed in this table, the key is
shared.
--- quote ---
'HKEY_CLASSES_ROOT\\Classes' -> 'HKEY_LOCAL_MACHINE\\Software\\Classes' =
shared between both.
MIME-type database key is a child key. It's not listed in table but the parent
key is, hence it should be shared between both views.
Additionally I found these keys:
--- snip ---
[HKEY_CLASSES_ROOT\Wow6432Node\MIME]
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database]
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content Type]
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content
Type\application/futuresplash]
"CLSID"="{D27CDB6E-AE6D-11cf-96B8-444553540000}"
"Extension"=".spl"
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content
Type\application/x-complus]
"CLSID"="{DC5DA001-7CD4-11D2-8ED9-D8C857F98FE3}"
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content Type\application/x-dwf]
"CLSID"="{A662DA7E-CCB7-4743-B71A-D817F6D575DF}"
"Extension"=".dwf"
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content
Type\application/x-ms-application]
"Extension"=".application"
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content
Type\application/x-shockwave-flash]
"CLSID"="{D27CDB6E-AE6D-11cf-96B8-444553540000}"
"Extension"=".swf"
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content Type\drawing/x-dwf]
"CLSID"="{A662DA7E-CCB7-4743-B71A-D817F6D575DF}"
"Extension"=".dwf"
[HKEY_CLASSES_ROOT\Wow6432Node\MIME\Database\Content Type\Model/vnd.dwf]
"CLSID"="{A662DA7E-CCB7-4743-B71A-D817F6D575DF}"
"Extension"=".dwf"
--- snip ---
Having the app-specific MIME-type database entries in the 32-bit-only view
looks wrong as well. Sometimes there are broken apps which use hard-coded
'Wow6432Node' in the key name but this one doesn't do that.
Wine source:
https://source.winehq.org/git/wine.git/blob/310019789f7bde12ae3f25f723957c975fb2f804:/server/registry.c#l1790
--- snip ---
1790 /* registry initialisation */
1791 void init_registry(void)
1792 {
1793 static const WCHAR HKLM[] = { 'M','a','c','h','i','n','e' };
1794 static const WCHAR HKU_default[] = {
'U','s','e','r','\\','.','D','e','f','a','u','l','t' };
1795 static const WCHAR classes[] = {'S','o','f','t','w','a','r','e','\\',
1796 'C','l','a','s','s','e','s','\\',
1797
'W','o','w','6','4','3','2','N','o','d','e'};
1798 static const struct unicode_str root_name = { NULL, 0 };
1799 static const struct unicode_str HKLM_name = { HKLM, sizeof(HKLM) };
1800 static const struct unicode_str HKU_name = { HKU_default,
sizeof(HKU_default) };
1801 static const struct unicode_str classes_name = { classes,
sizeof(classes) };
1802
1803 WCHAR *current_user_path;
1804 struct unicode_str current_user_str;
1805 struct key *key, *hklm, *hkcu;
1806 char *p;
1807
1808 /* switch to the config dir */
1809
1810 if (fchdir( config_dir_fd ) == -1) fatal_error( "chdir to config dir:
%s\n", strerror( errno ));
1811
1812 /* create the root key */
1813 root_key = alloc_key( &root_name, current_time );
1814 assert( root_key );
1815 make_object_permanent( &root_key->obj );
1816
1817 /* load system.reg into Registry\Machine */
1818
1819 if (!(hklm = create_key_recursive( root_key, &HKLM_name, current_time
)))
1820 fatal_error( "could not create Machine registry key\n" );
1821
1822 if (!load_init_registry_from_file( "system.reg", hklm ))
1823 {
1824 if ((p = getenv( "WINEARCH" )) && !strcmp( p, "win32" ))
1825 prefix_type = PREFIX_32BIT;
1826 else
1827 prefix_type = sizeof(void *) > sizeof(int) ? PREFIX_64BIT :
PREFIX_32BIT;
1828 }
1829 else if (prefix_type == PREFIX_UNKNOWN)
1830 prefix_type = PREFIX_32BIT;
1831
1832 /* load userdef.reg into Registry\User\.Default */
1833
1834 if (!(key = create_key_recursive( root_key, &HKU_name, current_time
)))
1835 fatal_error( "could not create User\\.Default registry key\n" );
1836
1837 load_init_registry_from_file( "userdef.reg", key );
1838 release_object( key );
1839
1840 /* load user.reg into HKEY_CURRENT_USER */
1841
1842 /* FIXME: match default user in token.c. should get from process token
instead */
1843 current_user_path = format_user_registry_path(
security_local_user_sid, ¤t_user_str );
1844 if (!current_user_path ||
1845 !(hkcu = create_key_recursive( root_key, ¤t_user_str,
current_time )))
1846 fatal_error( "could not create HKEY_CURRENT_USER registry key\n"
);
1847 free( current_user_path );
1848 load_init_registry_from_file( "user.reg", hkcu );
1849
1850 /* set the shared flag on Software\Classes\Wow6432Node */
1851 if (prefix_type == PREFIX_64BIT)
1852 {
1853 if ((key = create_key_recursive( hklm, &classes_name, current_time
)))
1854 {
1855 key->flags |= KEY_WOWSHARE;
1856 release_object( key );
1857 }
1858 /* FIXME: handle HKCU too */
1859 }
--- snip ---
Commit:
https://source.winehq.org/git/wine.git/commitdiff/178cd20e281d89358dde524f06882e0c8e0909bc
("server: Add support for Wow64 sharing of the HKLM\Software\Classes key.").
I'm stumped to find such a fundamental problem after years. But maybe I'm
totally off here, getting wrong conclusions from the code.
$ wine --version
wine-6.0-rc1-29-g310019789f7
Regards
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
More information about the wine-bugs
mailing list