How ancient is your Vulkan loader? This was fixed upstream like four or five years ago by making sure to only load DXGI from system32, unless they reintroduced this issue very recently for whatever reason.
Either way, this cannot work. The alternative to a deadlock is a stack overflow, or we deliberately detect this case, throw an error and still have things crash in some way.
How ancient is your Vulkan loader?
This stacktrace was produced with my local build from https://github.com/KhronosGroup/Vulkan-Loader/commit/c758bac8bf1580b5018adafd3a2ec709237b0134 Date: Tue Sep 3 15:55:31 2024 -0500
Normally I use one from GPU driver, which is currently 1.3.283 and hangs the same way, but I didn't have symbols for that, so I used the build above.
This was fixed upstream like four or five years ago by making sure to only load DXGI from system32
Ok, got it, so in fact we don't want to override dxgi.dll. Wiki says we can, but clearly it doesn't work.
It is possible to work around games loading the wrong DLL by enabling DevOverride in the registry.
Not possible in fact.
Thanks, I guess not much DXVK can do here.
This actually becomes a problem when DLL redirection is in use. As a workaround, I've copied the real C:\Windows\System32\dxgi.dll to C:\Windows\System32\dxgi_real.dll and patched the loader:
diff --git a/loader/loader_windows.c b/loader/loader_windows.c
index 31bbdfe9c..d6f65b0f3 100644
--- a/loader/loader_windows.c
+++ b/loader/loader_windows.c
@@ -83,8 +83,13 @@ void windows_initialization(void) {
wchar_t systemPath[MAX_PATH] = L"";
GetSystemDirectoryW(systemPath, MAX_PATH);
- StringCchCatW(systemPath, MAX_PATH, L"\\dxgi.dll");
+ StringCchCatW(systemPath, MAX_PATH, L"\\dxgi_real.dll");
HMODULE dxgi_module = LoadLibraryW(systemPath);
+ if (dxgi_module == NULL) {
+ GetSystemDirectoryW(systemPath, MAX_PATH);
+ StringCchCatW(systemPath, MAX_PATH, L"\\dxgi.dll");
+ dxgi_module = LoadLibraryW(systemPath);
+ }
fpCreateDXGIFactory1 =
dxgi_module == NULL ? NULL : (PFN_CreateDXGIFactory1)(void *)GetProcAddress(dxgi_module, "CreateDXGIFactory1");
Not sure what's the best way to fix this though. Can DXVK maybe detect this and call the real CreateDXGIFactory1?
The Vulkan loader already tries to explicitly load the system DXGI.
So even if DXVK could detect this scenario (no idea how that would work), there isn't really a way to load the system DLL.
dxgi.dllx2 2025-11dxgi_real.dllx1 2025-11vulkan-1.dllx1 2024-09
createDxgiFactory deadlocks because, apparently, while it is being created, the Vulkan loader also attempts to create it. As we can see, DXVK uses an SRW lock for the Singleton class, which is not recursive, leading to a deadlock in this situation.
System information
Log files
Thanks,
Kacper