http://bugs.winehq.org/show_bug.cgi?id=60232 --- Comment #2 from nayuta65535@gmail.com --- Not in the sense of an application failing to work. I went and checked, and the answer turned out to be no, so I am posting what I measured even though it argues against part of my own report. iZotope's Product Portal, the client that installs and activates their plug-ins, calls GetCurrentHwProfileA once at startup and uses the guid it gets back as the identity of the machine. On a pristine wine-11.16 built from the release tarball (../configure --enable-archs=i386,x86_64 --with-x --with-dbus, no staging, no DLL overrides), with the Portal's HTTP cache emptied first so that only that run's traffic was in it: fixme:advapi:GetCurrentHwProfileA (00007FFFFE20B560) semi-stub https://productportal.izotope.com/api/entitlements?hostID=123400011234123412... which is the hardcoded {12340001-1234-1234-1234-123456789012} with the braces and dashes stripped. With a locally patched advapi32 that generates a guid and stores it in the registry, the same request carries that machine's own guid instead. But it still works. On that same pristine build I completed machine-bound ("comp") authorizations of two products against that constant, and the vendor accepted both. One of them, with the check before and after in the same log: 04:23:26 AUTHCHECK | iZotope Ozone 8 Elements | Not Authorized | (LicenseType: 0, AuthType: 3) 04:24:25 AUTHORIZE | AuthorizeProduct | Ozone 8 Elements | AuthType: 'comp' 04:24:25 AUTHORIZE | iZotope Ozone 8 Elements | Result: Success 04:24:34 AUTHCHECK | iZotope Ozone 8 Elements | AUTHORIZED | (LicenseType: 3, AuthType: 0) Products authorized earlier also still validate under the stub value. So no application is blocked by this, and I should not have implied otherwise. What remains is that every Wine installation presents the same machine identity to that licensing server, and machine-bound authorizations are all issued against it, where MSDN says the system generates the guid per hardware profile at install time. Whether that is worth implementing is your call. The other three, no. The NULL crash, GetCurrentHwProfileW always failing, and dwDockInfo all came out of running the same test binary on Windows 11 and on Wine on this machine, so they are mismatches with Windows rather than application reports. The crash does still reproduce on 11.16, at dlls/advapi32/advapi.c:87: =>0 GetCurrentHwProfileA+0x18 [dlls/advapi32/advapi.c:87] in advapi32 87 pInfo->dwDockInfo = DOCKINFO_DOCKED; If a narrower bug is more useful, I am happy to reduce this one to the crash alone, or to close it. -- 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.