Blender crashes on Huion graphic monitor #89815

New Issue

Imre Meszaros · 2021-07-12T14:37:09+02:00

Imre Meszaros commented

2021-07-12 14:37:09 +02:00

{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.

Imre Meszaros commented

2021-07-12 14:37:09 +02:00

Added subscriber: @imremeszaros

Robert Guetzkow commented

2021-07-12 20:07:53 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2021-07-12 20:07:53 +02:00

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

Robert Guetzkow commented

2021-07-12 20:07:53 +02:00

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)

Imre Meszaros commented

2021-07-13 11:43:38 +02:00

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

Robert Guetzkow commented

2021-07-13 11:51:15 +02:00

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

Imre Meszaros commented

2021-07-23 12:03:06 +02:00

Any news?

Robert Guetzkow commented

2021-07-23 12:24:19 +02:00

@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.

Imre Meszaros commented

2021-07-23 12:59:59 +02:00

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.

Robert Guetzkow commented

2021-07-23 13:15:13 +02:00

@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\`.

Imre Meszaros commented

2021-07-23 13:46:32 +02:00

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

Robert Guetzkow commented

2021-07-23 15:58:24 +02:00

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)

Brecht Van Lommel commented

2021-07-26 16:31:38 +02:00

Added subscribers: @PrototypeNM1, @Harley, @brecht

Brecht Van Lommel commented

2021-07-26 16:31:39 +02:00

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, ```

Harley Acheson commented

2021-07-26 17:23:26 +02:00

Added subscriber: @LazyDodo

Harley Acheson commented

2021-07-26 17:23:26 +02:00

@LazyDodo - Can you wade in?

Ray molenkamp commented

2021-07-26 17:35:20 +02:00

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.

Nicholas Rishel commented

2021-07-26 18:56:30 +02:00

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 ```

Harley Acheson commented

2021-07-26 19:29:32 +02:00

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

Nicholas Rishel commented

2021-09-30 22:01:13 +02:00

Removed subscriber: @PrototypeNM1

Pratik Borhade commented

2022-01-26 06:45:54 +01:00

Added subscribers: @bernieb, @PratikPB2123

Pratik Borhade commented

2022-01-26 06:45:54 +01:00

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

Pratik Borhade commented

2022-02-25 14:23:21 +01:00

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

Alphyn commented

2022-12-09 13:33:07 +01:00

Added subscriber: @Alphyn

Alphyn commented

2022-12-09 13:33:07 +01:00

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).

Thomas Dinges added this to the 2.93 LTS milestone 2023-02-07 18:40:56 +01:00

Pratik Borhade commented

2023-07-31 12:39:21 +02:00

Hi, will close the report since 2.93 is EOL now: https://projects.blender.org/blender/blender/milestone/4
@Alphyn , could you open a new report for that? Might be different than this report.

Hi, will close the report since 2.93 is EOL now: https://projects.blender.org/blender/blender/milestone/4 @Alphyn , could you open a new report for that? Might be different than this report.

Pratik Borhade closed this issue

2023-07-31 12:39:23 +02:00

Blender Bot added

and removed

labels 2023-07-31 12:39:25 +02:00

Sign in to join this conversation.