vkCreateWin32SurfaceKHR hangs forever

[vulkan12d]

Of course, this only occurs on one computer, and all other test computers work fine. I was hoping that in

C:\VulkanSDK\1.3.224.1\Lib

there would be

vulkan-1d.lib

in order to get a better stack trace, but alas every other library has a debug equivalent except for vulkan-1.lib

I know it will be some undefined behavior we have accidentally used, but the validation layers don’t seem to be showing anything obvious.

Any thoughts welcome.
Alan

[vulkan12d]

A bit of background. I have a common library for all the low level Vulkan. In a very small test program last night, it does not seem to hang, but the production program does. My own logging shows the same parameters being passed in for both programs. Ok the HWND, and Vulkan handle pointers vary on every run but you get the idea.

I guess my question is whether there is really advanced logging for inside a function like vkCreateWin32SurfaceKHR.

[vulkan12d]

Ok, after reading on Reddit by user kroOoze,

Your SDK is ancient, and I think new version does not have the pdb to save space.

The usefulness of the pdb is limited, as your app uses the dll of your driver, whilst the pdb is for the version of your SDK. Meanwhile debugging an optimized (Release mode) dll is also tricky even with pdb.

If you want a debugable Loader, you should download Vulkan-Loader and build it in Debug mode, then use that dll instead.

So I have downloaded and compiled the Vulkan-Loader for 1.3.224 ,

and now find I am hanging in

	CreateWin32SurfaceKHR	VkLayer_monitor.dll!0x00007ffe57641f00 (load symbols for additional information)

So just heading down the rabbit hole of downloading validation layers to follow the cookie trail…

[vulkan12d]

Ok, turning off all validation layers prevents the call from blocking… Hum…

[krOoze]

Have you tried disabling VK_LAYER_LUNARG_monitor specifically?

Anyway, monitor wouldn’t be in the validation layers. It is at LunarG/VulkanTools. Largely all it does though is to get the window title so it can restore it on destruction, so not much to be stuck at…

Before you go down rabit holes, make sure your install is sane and not corrupted. That means checking things like that there are no duplicate layers, and that everything has sane versions.

Additionally check implicitly enabled layers. Also during debugging check Modules tab for any *.dll running that has no business being there, and proceed to identify and uninstall the associated software.

And should need not mention it, but vkCreateWin32Surface use should be valid. That includes passing it valid VkInstance and valid usable HWND.

Is there anything particularly special about that one test computer compared to the working ones?

[vulkan12d]

Hi krOoze,

1st, I had to laugh in that the post on Reddit was from you, and now you are helping even more Thanks.
I can confirm that removing VK_LAYER_LUNARG_monitor removes the hang! So that is good. Knowing that it is interacting with the window title helps. So we are an MDI MFC application. So we have/are setting up that each MDI child window can target specific GPU’s. So it would be interesting to know which window title? The main application or the MDI child window. Now in our case, the HWND handle an off screen window, and we transfer the contents once the render queue has told us it’s done. Now that probably explains why the little test program works in that it a single top level window. Well the test program did allow multiple top level windows, rendering the same data uploaded onto the card, one with perspective transformation, and the other orthographic transformation. It sounds like we just don’t need VK_LAYER_LUNARG_monitor. What is really different with this computer? Ok, its got a Quadro P4200, however we have a spread of many different GPU cards from RTX3000, NVIDIA GeForce RTX 3060, to RTX3090, Radeon RX 570 Series, Intel(R) UHD Graphics 630, etc. Up until now, they’ve all worked, but there is nothing like another GPU to show up bugs Sometimes rabbit holes are good for the soul. I will download LunarG/VulkanTools to be able to step into it to see if I can see where it is hanging… At least I could then report back. I managed to get SpirV-Tools compiled as it is a dependancy for validation layers, but validation layers is getting lots of errors with various .cmake files not being found. I’ve been a VCXPROJ person way too long now, and I have to admit cmake is a big mystery and when they work, all is good, but when things break, I am a tad lost. Alas, it would be nice if all these existed as prebuilt’s, but I guess I am a rare beast when it comes to issues like this.

Again, thanks for the suggestions
Alan

[krOoze]

Hehe, well there’s like 30 % chance you’ll get me. It’s like other people have a life or IDK…

The monitor literally just calls GetWindowText on the HWND you pass. Perhaps try to call that function directly.

The docs say:

However, if the target window is not responding and it belongs to the calling application, GetWindowText will cause the calling application to become unresponsive.

So make sure your wndproc loop is not actually the one blocking it.

---

All the Vulkan side projects should largely build with just:

..\scripts\update_deps.py --arch x64
cmake -A x64 -C helper.cmake ..
cmake --build .

The first command downloads bunch of dependencies and generate helper.cmake. The second command consumes it and generates the project. The third command compiles it (or you can just open the *.sln and take over from there instead).

_{cough cough cmake is garbage though cough}

[vulkan12d]

Ok, by the time I finished last night, the P4200 was passing most of our regression tests, so that is good. The only difference I realised last night was this computer is the first building against 1.3.224.1. All the other computers are still an earlier release.

Um yes, GetWindowText / SetWindowText may be fussy if it is not running on the GUI thread, especially MFC. When on a different thread, one needs to resort to PostMessage to get across thread boundaries.

Now knowing what VK_LAYER_LUNARG_monitor is used for, we just don’t need it. My GPU programmer put it in there back in 2017 when playing with a simple single window test program.

Thanks for the tip on building projects. I will play once I am in Cairns.