[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]

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: [e-mail]
          Reporter: [e-mail]
      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-key...

--- 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/310019789f7bde12ae3f25f723957c97...

--- 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, &current_user_str );
1844     if (!current_user_path ||
1845         !(hkcu = create_key_recursive( root_key, &current_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/178cd20e281d89358dde524f06...
("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