protonscr

"Failed to open shared NT handle" warning spam in Warcraft III Reforged

dxvkopen d3d11probably not our bug
doitsujin/dxvk#5771 · opened 2026-07-03 by mike-code · updated 2026-08-03 · 3 comments · github
Mmike-code 2026-07-03 github

After updating wine-staging from 11.6 to 11.11, Warcraft III Reforged started flooding stderr with

warn:  DxvkMemoryAllocator::createImageResource: Failed to open shared NT handle

It prints continuously the whole time the game menu is open. Sitting in the menu for about a minute produces ~1500 lines.

Software information

W3 reforged launched with -graphicsapi Direct3D11, borderless windowed fullscreen. No mods. vsync off, frame cap via dxvk.conf.

System information

  • GPU: AMD Radeon RX 6950 XT
  • Driver: Mesa 26.1.3 (RADV NAVI21)
  • Wine version: wine-staging 11.11
  • DXVK version: master, built from git (commit ba5ae90e0)

Log files

wc3.log

Ddoitsujin maintainer 2026-07-03 github

Can't really do much if shared resources aren't working.

As for why they aren't working, dunno, this whole thing relies heavily on wine and if this started due to a wine update, it's probably more fruitful to bisect wine to at least get an idea what's causing the issue.

Mmike-code 2026-07-03 github

FWIW impact-wise I can't find anything actually wrong because the game menu looks complete, so I'm not entirely sure that the shared resources are truly not working in this case. The browser subprocess (game menu runs as CEF subprocess) stays up, so from the outside this log spam looks more like a debug information that dxvk attempts to open a null handle, fails, warns ~25 times a second, but whatever depends on the sharing evidently already has what it needs.

I might have been in the wrong by pointing out wine bump from 11.6 to 11.11 being the only change in my desktop environment as there might have been more to that which happened in parallel (shared libs, deps which I can't remember now).

Before attempting a wine bisect I tried the cheaper thing first and ran a session with WINEDEBUG=+d3dkmt (google search revealed those createImageResource logs may be related to D3DKMT) and noticed every single dxvk warning pairs up 1:1 with this on the wine side:

warn:d3dkmt:d3dkmt_object_open Failed to open global object 0/(nil), status 0xc0000008

so whatever NT handle dxvk is trying to open there is null. Meanwhile the same trace has plenty of successful share/open calls between the game and the CEF subprocess, which I assume is the sharing actually working.

My point being: even if there's some issue on the wine side, maybe dxvk should check before trying to open handles that were never (correctly?) exported. let me know if i can provide some more debug information

Ddoitsujin maintainer 2026-07-03 github

We already check whether vkGetMemoryWin32HandleKHR fails, which isn't the case here. Either that gives us a null handle (which it really shouldn't), or it gets lost elsewhere somehow.

Launch options

Error codes