[Caused by buggy software Nahimic] Viewport resizing outside of main application window leads to crashes #3321
Comments
|
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:
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'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. |
|
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've encountered the same problem but my call stack does not include Nahimic...
The bug persist after updating drivers... I am writing a UI library and this begs the question - should I move from OpenGL to Direct3D? I need something stable. |
|
Hello @thehorseisbrown I think this is something you need to bring up with Nvidia. |
|
Ok, I posted it on the Nvidia forum. I'm ditching Opengl for good tho :D this is the last drop. I really don't like smart pointers and interfaces but hopefully I get some good stability with D3D. It seems like 3rd party APIs should always be less likely to provide superior or equal stability. They don't have the money or the negotiating powers. But I agree that designing new APIs is a good thing. It would be awesome if GPU vendors had the upper hand and just put out new low level APIs whenever they wished and be like, hey have fun, you can do new cool things, write an API to your liking. There might be security issues with that tho. |
|
I'm closing this as "random stuff we can't seem to be able to fix on our side", however
|
|
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 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. 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 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) :
use case here with decoration on child viewports (for have resize by app) :
|
|
@aiekick Could you post your full callstack for the crash? (trying to manually load symbols when possible, maybe with additional Nvidia drivers symbols) |
|
Nothing really interesting. Callstack : Machine Code : this bug is related to the detroying of Framebuffer for me. |
Depending on your settings, you might need right-click on the stack frame and click "Load Symbols". Also did you try updating your graphics drivers as Omar suggested previously in the thread? |
|
yes i updated my drivers yesterday. in my case its not a problem because i activate the decoration, for have the possibility to :
|
|
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. |
|
@thehorseisbrown Another report on GLFW forums mention another software "Asus's Sonic Suite" do you have that by any chance? |
|
@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. |
|
@ocornut the Nahimic situation is absolutely insane! The issue came back after the last windows update and the above fix was not enough to pacify it this time. In a bout of desperation, went back to checking all services again, and sure enough it turns out I actually had an instance of Nahimic running. Got rid of it and apparently I don't even need the above fix anymore. While it does reduce the probability of crashes, it does not completely eliminate it if Nahimic is running. |
|
i think the same, this is why i choose this solution, fyi : #4534 |
|
I was looking into this a bit and found this thread from the Prusa Slicer team, who has also been dealing with this malware: prusa3d/PrusaSlicer#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. |
ocornut
changed the title
|
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? |
|
Hey, we have the same issue over at F3D, which does not use ImGui at all (yet^^). Just another point of data I guess. |
Update after further testing (detailed in comments below): The issue seems to originate from Nahimic interacting with OpenGL. Disabling/uninstalling Nahimic solved the issue for me.
Version/Branch of Dear ImGui:
Version: Dear ImGui 1.77 WIP (17602)
Branch: docking
Back-end/Renderer/Compiler/OS
Back-ends: imgui_impl_glfw.cpp + imgui_impl_opengl3.cpp / imgui_impl_opengl2.cpp
Compiler: MSVC 1926
Operating System: Windows 10 64bit
Graphics card: RTX 2080 (Driver version 451.48)
Monitors: Two monitors (1080p60, 1440p144 w/ G-Sync)
DxDiag with more system information available here:
DxDiag.txt
My Issue:
When using viewport and draging an ImGui window out of the main application window and then resizing the viewport ImGui window a variable amount (intensity and time), the whole application suddenly crashes and throws an exception:
(specific memory addresses vary from run to run)
With following callstack:
Visual Studio claims the current stack frame is not in module and therefore cannot show any source. This is an extract from the disassembly though:
Changing the thread to main thread in the debugger provides the following callstack:
Some more test scenarios
Issue persisted:
Issue seemingly was not present:
Screenshots/Video
Additional more detailed videos:
These are on youtube as they were too large to host on GitHub
There are two videos, one shows the issue on a clean checkout version of example_glfw_opengl3 and the other shows it on a slightly lighter version with docking and extra windows and components disabled.
In both the videos I try to show how moving or resizing the ImGui window within the main application window does not present an issue, also moving the ImGui window outside the main application window also does not present an issue. It's only when resizing the ImGui window outside of the main application window that the issue shows itself.
Clean repo checkout: https://youtu.be/SCUHu8g2PnU
Stripped down: https://youtu.be/oYtw8yZ8eKQ
Standalone, minimal, complete and verifiable example:
Tested on clean checkout examples from docking branch, both example_glfw_opengl2 and example_glfw_opengl3. On these examples, disabling docking and using only a basic window with text on it still causes the issue.
Additional information
Asserts are turned on.
Here is an example of imgui.ini after a crash:
(I tried providing as much information as I could regarding the issue, but this is also my first time submitting a report like this, so I apologize if I missed any important piece of information or if this issue already was known and I just didn't find it when I searched)
The text was updated successfully, but these errors were encountered: