glfwInit takes 20 seconds

Question

I never had an issue with this until recently, but glfwInit() always takes 20 seconds to execute. I have seen the other stackoverflows and github issues pertaining to driver issues - but I do not have the same devices as the ones people talk about, and with the devices and drivers (fully updated) I do have, I have never had this issue until now.


    RB_CORE_INFO("Creating window {0} ({1}, {2})", props.title, props.width, props.height); // log macro - for example, will print at 10:30:00

    if (!gGlfwInitialized)
    {
        RB_CORE_TRACE("Initializing GLFW"); // prints at 10:30:00

        const int success = glfwInit(); // takes 20 seconds
        RB_CORE_ASSERT(success, "Could not initialize GLFW")
        RB_CORE_TRACE("GLFW Initialized"); // prints at 10:30:20

        glfwSetErrorCallback(GlfwErrorCallback);

        gGlfwInitialized = true;
    }

    RB_CORE_TRACE("Creating glfw window");
    mWindow = glfwCreateWindow(static_cast<int>(props.width), static_cast<int>(props.height), mData.title.c_str(),
                               nullptr, nullptr);

A snippet of my code, though I'm quite positive the issue is not my code. Whether my issue is glfw or windows 11 I am not sure, but I'm going mad trying to figure it out. Other work arounds and causes I've found online do not seem to be my case, as far as I can figure at least.

Any help is greatly appreciated.

For reference, I run Windows 11, fully updated and all drivers updated. RTX 3080 gpu and a Ryzen 5900x cpu. Some people have blamed Corsair keyboards, though I have a Ducky keyboard and it doesn't seem to be the cause either.

Note: I've rebooted many times since I first started having this issue a couple days ago.

Edit: It does seem the issue is related to this and this however these point to a device driver with VID_262 in the hardware ID. But as I do not have any with that particular VID_262 I'm not sure where to start looking. Using DevCon.exe I generated this list but even after unplugging every device one by one, I can't find the issue. As of this edit, I've not yet been able to try running this on another device.

Make sure this is not caused by your code (try some simple GLFW example). If the same thing happens, try it in a VM or on a different machine. If it happens there too, build GLFW yourself with debug info, and debug it. — HolyBlackCat, Jun 16 '22 at 20:37
@TedLyngmo No it does not. I've rebooted many times since I first started having this issue a couple days ago. — TigerCipher, Jun 16 '22 at 20:38
Run your app under the debugger and break into it while it's initialising ('caveman profiling'). Doing that a few times usually reveals what's going on, but as @HolyBlackCat says, you might need to build GLFW with debug symbols to get a meaningful stack trace. — Paul Sanders, Jun 16 '22 at 20:44
If it just started a couple of days ago I'd start thinking about what has changed in your setup recently. Windows Updates? Graphics Driver? Installed any new applications? — Retired Ninja, Jun 16 '22 at 20:49
@HolyBlackCat Happens with other glfw projects, including example code. Will have to try different machine later today. I do build glfw myself via premake5, and assuming im correct that `symbols "On"` and `runtime "Debug"` are the correct settings to set, then I do indeed build with debug info I believe - though at least running from visual studio and setting breakpoints, it won't actually let me use the breakpoints - says "No executable code of the debugger's target code type is associated with this line" (at least within glfwInit in init.c) — TigerCipher, Jun 16 '22 at 20:49
@RetiredNinja Other than steam updates, nothing - unless something was done in the background — TigerCipher, Jun 16 '22 at 20:50
Then try using prebuilt GLFW for a change, see if it still happens. If it doesn't help switch back to your own debug build, and instead of putting breakpoints, pause the program and inspect the stack. If the stack doesn't display immediately, there should be buttons to point VS to symbols/source code. — HolyBlackCat, Jun 16 '22 at 20:51
@HolyBlackCat Ah thank you, I didn't actually think about that. It seems to get stuck on the IDirectInput8_EnumDevices check that is shown in [this issue](https://stackoverflow.com/questions/10967795/directinput8-enumdevices-sometimes-painfully-slow) though it mentions specific drivers I do not even have, so I'm not actually sure where to go from here — TigerCipher, Jun 16 '22 at 20:57
I'd report it as a bug then. Before that you can try to disable your antivirus, or try to remember any wonky drivers you might've had installed. — HolyBlackCat, Jun 16 '22 at 21:03
@HolyBlackCat I wouldn't, it's not GLFW's fault. Rather, as per the OPs link, disable the offending driver, once you have identified it, and move on. — Paul Sanders, Jun 16 '22 at 21:04
@PaulSanders I don't suppose you have any suggestions on figuring out the offending driver? — TigerCipher, Jun 16 '22 at 21:06
https://learn.microsoft.com/en-us/sysinternals/downloads/procmon may shed some light on what's going on. — Retired Ninja, Jun 16 '22 at 21:09
Sorry, no, but the link you tracked down has some promising suggestions. — Paul Sanders, Jun 16 '22 at 21:09

score 0 · Answer 1 · answered Jun 18 '22 at 18:27

So it turns out VCPKG is evil. I started having more issues - being that ImGui first compiled, but would give me read access violations when I used their NewFrame function. Then it turned into linking errors and a whole bunch of things that really started to confuse me. Even though I'm taking all my libraries from my own folder via premake, it seems Visual Studio has gotten confused and was trying to link both my generated lib files with lib files I had installed on vcpkg.

Turning off vcpkg has fixed both my linking errors and now makes glfw init very fast. I guess I should just uninstall vcpkg completely so it fixes the problem for other games or applications that use things like glfw.

Long story short, VCPKG is a nightmare on my system.

glfwInit takes 20 seconds

1 Answers1