imgui: [Caused by buggy software Nahimic] Viewport resizing outside of main application window leads to crashes

@aiekick I have exactly the same issue on Win11 / RTX 3070 GPU. Thank you so much for your diagnosis that resizing only on one axis does not crash! This was the insight I needed to make an acceptable workaround that seems to have solved it for me.

Basically, I implemented a simple alternating Width/Height resize, like so:

protected override void OnResize(EventArgs e)
{
    if (hresize) canvas.Size = new Size(Width, canvas.Height);
    else canvas.Size = new Size(canvas.Width, Height);
    base.OnResize(e);
    resizing = true;
}

and synchronize the Axis change to SwapBuffers, like so:

        canvas.SwapBuffers();
        if (resizing)
        {
            hresize = !hresize;
            resizing = false;
        }

Surprisingly, this completely eliminated the problem and I can now run as many circles around the corner grab without any crashes. Also at ~60 fps rendering you’ll be hard pressed to notice any perceptually noticeable change. It’s totally crazy, and I don’t get at all what is going on, but one less issue off my back. It was really hard to find anything else online that referred to this problem.

To be clear, I don’t think this has anything to do with either imgui or GLFW, as my stack uses neither, but I still experience the exact same symptoms as described by @aiekick.

PS: For reference, I also don’t have ASUS Sonic Suite or any of the other problematic software packages mentioned above.

Hello,

I struggled with the same issue and thanks to you here finally it works. There’s a Nahimic service, it seems to be enough to disable the service. I don’t understand why Nahimic is in the call stack, there is nothing that requires audio.

In my case the ATI driver crashed, caused by NahmicOSD.dll

PS: It seems to be part of my sound software Sonic Studio with Realtek hardware.

I’d like to contribute my experience with Nahimic Service being a hinderance to my game development work.

I came across this Github bug thread a while back and was able to realize that my game development tools were crashing due to the Nahimic Service. It’s been a while, but since the latest Windows 11 Updates, Nahimic Service is installed once again and back up and running. I had totally forgotten about it. My game dev tools were crashing again, and it hit me that it was this awful service once again.

Here is a video recording of my game dev tools crashing after I resize the editor windows. The software used here is Python and OpenGL via wxWidgets (wxPython). In the video, I resize the window quite erratically to get the crash to occur. Often times I have multiple editor windows open at the same time which causes the crash to happen much quicker. Sometimes my software crashes, and I am doing nothing.

https://www.youtube.com/watch?v=7wJvU4yp_SY

This Nahimic Service is awful. It is some sort of audio driver that somehow crashes other apps when resizing windows. I have absolutely no clue what is going on under the hood, but it is terrible and reprehensible beyond words. What kind of trash software driver which has nothing to do with graphical operations cause crashes when its purpose is to provide audio functionality?

I have the same issue but the difference is I don’t use ImGui. As far as I also tested with macOS (M1), the problem seems to happen both on Windows and macOS. Therefore I suspect the problem is on the glfw side.

I’ve done some more testing now and it seems, as you suspected, that the culprit was indeed Nahimic. After disabling it I haven’t encountered the issue anymore. More specifically and for reference these are the tests I performed (all with the latest Nvidia driver installed):

I didn’t test any minimal glfw or SDL-only examples as Nahimic seems to be the culprit together with OpenGL somehow. The easy way out is ofc to disable Nahimic, but considering it comes pre-installed on so many computers it would be nice if there was a workaround.

Either way, I believe this concludes the issue at least from my part. Thanks for the suggestions (:

Edit: I’m leaving the issue open in case you want to pursue it somehow, but otherwise feel free to close it.

Thank you Alex for such a careful and detailed report. This is likely going to be tricky to solve, but before I am able to attempt a repro (I’m not on my computer today), some early thoughts:

Instinctively I feel this is likely going to be an issue not linked to Dear ImGui. The inner loop of interacting with GLFW and OpenGL are pretty standards. I sense there’s a chance the answer won’t be something that we can action from the point of view of Dear ImGui’s examples/backends, but it would be worth investigating.

For completeness, here what I would do:

• Try to repro with the SDL+OpenGL example in Dear ImGui repository.

• Your callstack shows NahimicOSD.dll (on screen display for Nahimic). While I don’t have ample evidence outside of my use case, all of my personal experience with Nahimic led me to conclude it was buggy software. Anecdotally: I almost returned my current laptop after purchasing it, but it ended up being Nahimic severely breaking audio on the computer. May I suggest uninstalling it to see if whatever it is attempting to do with its OSD hook isn’t the cause of your crash.

• I would try to update Nvidia drivers. Consider OpenGL is increasingly neglected by GPU drivers and fast resizing a GL framebuffer may lead to bugs.

• I would try to repro the same thing without any Dear ImGui code. That is, by creating 2 or more GLFW windows and programatically resizing one every frame using GlfwSetWindowSize(). If the bug repo, that gives us a confirmation dear imgui isn’t really the cause.

• Even if Dear ImGui isn’t the culprit and we want to chase that, know that depending on what else we find, it might be worth implementing some workaround on Dear ImGui’s backends side.

Again, those are thoughts in case you wanted to pursue this. I haven’t tried reproducing on my computer yet (will do), but also I don’t recall anyone reporting such crash in the past and I surely having seen it myself.

I was looking into this a bit and found this thread from the Prusa Slicer team, who has also been dealing with this malware: https://github.com/prusa3d/PrusaSlicer/issues/5573

They did some investigation into preventing the injection in the first place, but unfortunately never quite arrived to a solution. Their solution in the end was to try and detect if Nahimic was injected and if it is show a warning dialog to the user.

Showing a warning dialog from the backend seems excessive, but maybe we can automatically disable viewports or force @aiekick’s workaround when it’s detected? (Their detection logic is pretty simple.)

It’s not ideal, but it’s better than Dear ImGui apps crashing whenever they’re run on infected systems. It seems more OEMs beyond MSI have been signing up with Nahimic lately, so I feel this problem will only be getting worse.

As an aside, I came across a (non-programmatic) way to tell Nahimic to ignore certain apps. https://chieftalk.chiefarchitect.com/topic/28384-multi-monitor-issue-fix-for-computers-with-nahimic-audio/ It’s not ideal, but it’s probably more robust than asking people to disable the service since this presumably survives updates.

sorry to dig up, this post, but i have indentified the crash case i guess

I have the same issue in all my softs who are using ImGui Docking with glfw3 and opengl3 backend I have not the issue with glfw3 and vulkan backends

it seem the crash happen, only when i tried to resize the window with the imgui drawn grip.

if i enable glfw decoration on child windows and resize the window on the window (edges or corners) and not with the grip. there is no issue, and it seem too, there is no lag between “we want the resize” and “the resize happen”

if i resize with the imgui grip, there is a lag between “we want the resize” and “the resize happen”, and the app crash when the mouse cursor become outside of the windows during the resize. (during this lag)

like said i have the issue only when i try to resize with the grip. if i use the borders i have no issues. maybe a workaround can be to disable the grip and have the resize on windows corner in the same way as edges. btw not found a way to dsiable the grip, i will try to explore in deep.

i commented the glfwSwapBuffers of the main window and after many resized vs2019 locate the issue near the glfwSwapBuffers of child viewport. its correspond to the issue we have occured in gpu driver. on my system nvogl.dll there is some similar issues on glfw forum by ex this one : https://github.com/glfw/glfw/issues/1682 or this one https://github.com/glfw/glfw/issues/905

he seem not to be the fault of imgui, but there is a bug somewhere around glfwSetWindowSize in some cases and glfwSwapBuffers

use case here with no decoration on child viewports (standard case) :

• vertcial and horizontal resize => no issue
• corner resize on grip => crash

use case here with decoration on child viewports (for have resize by app) :

• vertcial and horizontal resize => no issue
• corner resize handle by windows => no crash
• corner resize by the grip => crash