Blender crashes on Huion graphic monitor #89815

New Issue

{F10221600}System Information
Operating system: Windows 10 64bit pro
Graphics card: 2x RTX2080

Blender Version
Broken: 2.93.1

Short description of error
Blender is randomly crashing on my HUION kamvas Pro 22 Graphic monitor, whenever I open the "export", "imoprt", "open", or "save as" windows. When on my other monitor (standard non-graphic monitor) the crashes are not happening.

{[F10221600](https://archive.blender.org/developer/F10221600/system-info.txt)}**System Information** Operating system: Windows 10 64bit pro Graphics card: 2x RTX2080 **Blender Version** Broken: 2.93.1 **Short description of error** Blender is randomly crashing on my HUION kamvas Pro 22 Graphic monitor, whenever I open the "export", "imoprt", "open", or "save as" windows. When on my other monitor (standard non-graphic monitor) the crashes are not happening.

Added subscriber: @imremeszaros

Added subscriber: @rjg

Changed status from 'Needs Triage' to: 'Needs User Info'

Please open Blender's installation directory and double click on the blender_debug_gpu.cmd. This will start Blender in debug mode and create log files. Try to make Blender crash again. Once it crashes the Windows Explorer should open and show you up to two files, a debug log and the system information. Add them to your bug report by clicking on the upload button as shown in the screenshot below or via drag and drop. Please also upload the crash log located in C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt (or simply type %TEMP% into the path bar of the Windows Explorer).

Please open Blender's installation directory and double click on the `blender_debug_gpu.cmd`. This will start Blender in debug mode and create log files. Try to make Blender crash again. Once it crashes the Windows Explorer should open and show you up to two files, a debug log and the system information. Add them to your bug report by clicking on the upload button as shown in the screenshot below or via drag and drop. Please also upload the crash log located in `C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt` (or simply type `%TEMP%` into the path bar of the Windows Explorer). ![2019_12_04_upload_icon_developer_blender_org.png](https://archive.blender.org/developer/F8190038/2019_12_04_upload_icon_developer_blender_org.png)

blender_system_info.txt

blender_debug_output.txt

blender.exe.4092.dmp

Hi Robert,

These are the only files created by Windows at the time of the crash. Also tried with the earlier Blender version (2.92). That works,and doesn't crash. On 2.93.1 it looks like Blender tries to resize the window, as I open fbx export or import. It flickers a couple of times then it quits with no error message whatsoever.
Thanks for your help, and best regards!

Imre

[blender_system_info.txt](https://archive.blender.org/developer/F10222880/blender_system_info.txt) [blender_debug_output.txt](https://archive.blender.org/developer/F10222879/blender_debug_output.txt) [blender.exe.4092.dmp](https://archive.blender.org/developer/F10222891/blender.exe.4092.dmp) Hi Robert, These are the only files created by Windows at the time of the crash. Also tried with the earlier Blender version (2.92). That works,and doesn't crash. On 2.93.1 it looks like Blender tries to resize the window, as I open fbx export or import. It flickers a couple of times then it quits with no error message whatsoever. Thanks for your help, and best regards! Imre

Changed status from 'Needs User Info' to: 'Needs Triage'

Any news?

@imremeszaros Please try to update your Huion driver and check if this resolves the issue. In case it doesn't please check if you find a .crash.txt file as described above, because that would contain the stack trace that allows us to narrow down the issue. Based on the current description this could be a problem with the wintab.dll of the driver.

@imremeszaros Please try to update your Huion driver and check if this resolves the issue. In case it doesn't please check if you find a `.crash.txt` file as described above, because that would contain the stack trace that allows us to narrow down the issue. Based on the current description this could be a problem with the `wintab.dll` of the driver.

Thanks Robert, but how can it be the Huion driver's fault if the other programs run perfectly on it, and the other Blender versions too? It's more likely to be a problem with Blender 2.93. My drivers are the latest. I have downloaded the latest experimental Blender builds and 2.93.2 crashes the same way, but 3.0 and 2.83.17 don't. 2.92 does not crash either. Also this is a version 2.93 only problem. I searched windows explorer for *.crash.txt but found nothing.

@imremeszaros Right, that does sound more like an issue in Blender 2.93.x. Could you please check if starting Blender 2.93.x temporarily with the default user preferences by opening Blender's installation directory and double clicking on the blender_factory_startup.cmd avoids the crash?

If a .crash.txt would have been written, it would be located in C:\Users\Administrator\AppData\Local\Temp\.

@imremeszaros Right, that does sound more like an issue in Blender 2.93.x. Could you please check if starting Blender 2.93.x temporarily with the default user preferences by opening Blender's installation directory and double clicking on the `blender_factory_startup.cmd` avoids the crash? If a `.crash.txt` would have been written, it would be located in `C:\Users\Administrator\AppData\Local\Temp\`.

Tried it. It crashes the same way. No .crash.txt either.

Stack trace from the crash dump can be found here, thanks to Ray: P2278

Stack trace from the crash dump can be found here, thanks to Ray: [P2278](https://archive.blender.org/developer/P2278.txt)

Added subscribers: @PrototypeNM1, @Harley, @brecht

I'm guessing this is related to one of the changes by @Harley or @PrototypeNM1 but it's hard to tell from the backtrace which change, it's potentially some indirect effect.

I'd prefer a Windows developer looks at this, but will give a quick analysis.

From the backtrace, this looks like a problem where dispatchEvents() is called recursively when it shouldn't be. Two potential causes:

m_inLiveResize is set when no actual live resize is happening, causing move and resize events to dispatch events immediately. Does not seem super likely to me.
WM_DPICHANGED event is sent on window creation (maybe only for certain types of monitors), causing an unchecked recursivedispatchEvents().

Really we shouldn't need to dispatch events immediately here, and someone could test if removing that code solves the issue. And if so, if removing it causes some other bug that should be solved another way, or if it's entirely unnecessary.

diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp
index 4f5e957..697ed4b 100644
--- a/intern/ghost/intern/GHOST_SystemWin32.cpp
+++ b/intern/ghost/intern/GHOST_SystemWin32.cpp
@@ -1873,8 +1873,6 @@ LRESULT WINAPI GHOST_SystemWin32::s_wndProc(HWND hwnd, UINT msg, WPARAM wParam,
 
             // Push DPI change event first
             system->pushEvent(processWindowEvent(GHOST_kEventWindowDPIHintChanged, window));
-            system->dispatchEvents();
-            eventHandled = true;
 
             // Then move and resize window
             SetWindowPos(hwnd,

I'm guessing this is related to one of the changes by @Harley or @PrototypeNM1 but it's hard to tell from the backtrace which change, it's potentially some indirect effect. I'd prefer a Windows developer looks at this, but will give a quick analysis. From the backtrace, this looks like a problem where `dispatchEvents()` is called recursively when it shouldn't be. Two potential causes: * `m_inLiveResize` is set when no actual live resize is happening, causing move and resize events to dispatch events immediately. Does not seem super likely to me. * `WM_DPICHANGED` event is sent on window creation (maybe only for certain types of monitors), causing an unchecked recursive`dispatchEvents()`. Really we shouldn't need to dispatch events immediately here, and someone could test if removing that code solves the issue. And if so, if removing it causes some other bug that should be solved another way, or if it's entirely unnecessary. ``` diff --git a/intern/ghost/intern/GHOST_SystemWin32.cpp b/intern/ghost/intern/GHOST_SystemWin32.cpp index 4f5e957..697ed4b 100644 --- a/intern/ghost/intern/GHOST_SystemWin32.cpp +++ b/intern/ghost/intern/GHOST_SystemWin32.cpp @@ -1873,8 +1873,6 @@ LRESULT WINAPI GHOST_SystemWin32::s_wndProc(HWND hwnd, UINT msg, WPARAM wParam, // Push DPI change event first system->pushEvent(processWindowEvent(GHOST_kEventWindowDPIHintChanged, window)); - system->dispatchEvents(); - eventHandled = true; // Then move and resize window SetWindowPos(hwnd, ```

Added subscriber: @LazyDodo

@LazyDodo - Can you wade in?

I can't reproduce the issue, judging by the stack trace I'd say SetWindowPlacement seems to be recursively calling the wndproc, but given it only hits 2.93 and not 2.92/3.0 makes me less sure about that analysis, also unsure why this is only hitting some users not all, if either @Harley or @PrototypeNM1 have an idea what's going on here i'm all ears.

gut instinct is put a check before setwindowplacement so we don't call it if it's not needed, but my gut instincts are often wrong.

I can't reproduce the issue, judging by the stack trace I'd say `SetWindowPlacement` seems to be recursively calling the wndproc, but given it only hits 2.93 and not 2.92/3.0 makes me less sure about that analysis, also unsure why this is only hitting some users not all, if either @Harley or @PrototypeNM1 have an idea what's going on here i'm all ears. gut instinct is put a check before setwindowplacement so we don't call it if it's not needed, but my gut instincts are often wrong.

All the window sizing/moving code follows a similar dispatchEvents pattern. I'm assuming this is to force synchronization of Blender's window layout and ghost events post-window change, which could be necessary if window layout is only updated after all ghost events are handled. This probably shouldn't happen while in the Win32 event callback, but any solution that comes to mind involves messy rewiring so I'd prefer to avoid this unless it's confirmed as the problem.

Can anyone summarize what the following is doing?

wm_window_ghostwindow_add
wm_window_ghostwindow_ensure
WM_window_open
ED_screen_temp_space_open
wm_handler_fileselect_do

All the window sizing/moving code follows a similar `dispatchEvents` pattern. I'm assuming this is to force synchronization of Blender's window layout and ghost events post-window change, which could be necessary if window layout is only updated after all ghost events are handled. This probably shouldn't happen while in the Win32 event callback, but any solution that comes to mind involves messy rewiring so I'd prefer to avoid this unless it's confirmed as the problem. Can anyone summarize what the following is doing? ``` wm_window_ghostwindow_add wm_window_ghostwindow_ensure WM_window_open ED_screen_temp_space_open wm_handler_fileselect_do ```

I actually doubt this could be anything complicated or structural. The important things to keep in mind:

This error does not occur for OP using regular monitors, only with this one which also acts as pen tablet.
This error does not occur in blender 3.0

I actually doubt this could be anything complicated or structural. The important things to keep in mind: - This error does not occur for OP using regular monitors, only with this one *which also acts as pen tablet*. - This error does not occur in blender 3.0

Removed subscriber: @PrototypeNM1

Added subscribers: @bernieb, @PratikPB2123

This error does not occur for OP using regular monitors, only with this one which also acts as pen tablet.

@Harley Hi, I am not sure if tablet monitor is the culprit.
Similar problems were reported a few months back where crash occurred with regular monitors: #90559, #90111 and #91149
@bernieb has listed findings. That may help you for reproducing the problem: #90559#1205397

> This error does not occur for OP using regular monitors, only with this one which also acts as pen tablet. @Harley Hi, I am not sure if tablet monitor is the culprit. Similar problems were reported a few months back where crash occurred with regular monitors: #90559, #90111 and #91149 @bernieb has listed findings. That may help you for reproducing the problem: #90559#1205397

I have downloaded the latest experimental Blender builds and 2.93.2 crashes the same way, but 3.0 and 2.83.17 don't

That said, we could Move this report to BF Blender (2.93) project

> I have downloaded the latest experimental Blender builds and 2.93.2 crashes the same way, but 3.0 and 2.83.17 don't That said, we could Move this report to `BF Blender (2.93)` project

Added subscriber: @Alphyn

Hi everyone! I just wanted to say that this error occurs on Huion 4k screen tablet both on 3.4 release version and 3.3 LTS.
After Blender crashes once while opening any extra window (File explorer, Preferences, Render), blender will fail to start again until you reboot the PC.
The workaround is to delete/rename wintab.dll in System32, but it sure as heck breaks something else somewhere else. Pen pressure in Photoshop works fine at least (In Windows Ink mode).

Hi everyone! I just wanted to say that this error occurs on Huion 4k screen tablet both on 3.4 release version and 3.3 LTS. After Blender crashes once while opening any extra window (File explorer, Preferences, Render), blender will fail to start again until you reboot the PC. The workaround is to delete/rename wintab.dll in System32, but it sure as heck breaks something else somewhere else. Pen pressure in Photoshop works fine at least (In Windows Ink mode).

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender crashes on Huion graphic monitor #89815