Wintab rarely gets into a bad state and prevents Blender startup #111152

New Issue

Thomas Barlow · 2023-08-15T23:21:59+02:00

Thomas Barlow commented

2023-08-15 23:21:59 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.40

Blender Version
Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-08-14 21:32, hash: dd9a92785acc
Worked:

Short description of error
For a few months now, I have been getting a fairly rare, but reoccurring issue (maybe once a week on average) where Wintab gets into some erroneous state and prevents Blender from starting if the Tablet API setting of the Input preferences is set to Wintab or Automatic.
When Wintab gets into this erroneous state and Blender is already open, Blender will crash if I attempt to open the User Preferences. I'm not sure what else might cause a crash when Blender is already open.

By adding extra logging to a custom build of Blender, I've determined that the crash when starting Blender occurs when calling the open (WTOpenA) function: 86085bcb9c/intern/ghost/intern/GHOST_Wintab.cc (L85)

My drawing tablet's software also reports an exception in WTOpen, the value of which appears to equal 0xC0000005 which I think indicates a STATUS_ACCESS_VIOLATION according to https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55.

In the drawing tablet's software, this exception only occurs if I actually connect the tablet to my PC, whereas Blender crashes even when the tablet is not connected.

Currently, if I don't actually need my tablet, I'm working around the issue by starting Blender headless, changing the Tablet API setting to Windows Ink, and then starting Blender normally.

I have already tried updating the drivers for my tablet to the newest version and it made no difference.

If I start Blender with --debug-wintab, all that's printed is:

PS D:\Downloads\temp\blender-4.0.0-alpha+main.dd9a92785acc-windows.amd64-release> .\blender.exe --debug-wintab
Read prefs: "C:\Users\Thomas\AppData\Roaming\Blender Foundation\Blender\4.0\config\userpref.blend"
Loading Wintab for window 00000000000910C4
PS D:\Downloads\temp\blender-4.0.0-alpha+main.dd9a92785acc-windows.amd64-release>

Every version of Blender I've tried between 2.79 and 4.0.0a crashes unless I have the Tablet API set to Windows Ink.

I don't know the specifics of how Wintab is handled, but could it be possible to either catch the exception in WTOpen and allow Blender to continue loading, or to check for a connected tablet before attempting to call WTOpen, similar to what my tablet's software appears to be doing?

Exact steps for others to reproduce the error
Unfortunately, Wintab getting into this erroneous state where it crashes in WTOpen occurs too rarely for me to figure out how to reproduce it and I'm not even sure if it's Blender that is causing it to get into this state in the first place.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.40 **Blender Version** Broken: version: 4.0.0 Alpha, branch: main, commit date: 2023-08-14 21:32, hash: `dd9a92785acc` Worked: **Short description of error** For a few months now, I have been getting a fairly rare, but reoccurring issue (maybe once a week on average) where Wintab gets into some erroneous state and prevents Blender from starting if the Tablet API setting of the Input preferences is set to `Wintab` or `Automatic`. When Wintab gets into this erroneous state and Blender is already open, Blender will crash if I attempt to open the User Preferences. I'm not sure what else might cause a crash when Blender is already open. By adding extra logging to a custom build of Blender, I've determined that the crash when starting Blender occurs when calling the `open` (`WTOpenA`) function: https://projects.blender.org/blender/blender/src/commit/86085bcb9c50402387079d1d8ec7e3ab5b36c317/intern/ghost/intern/GHOST_Wintab.cc#L85 My drawing tablet's software also reports an exception in `WTOpen`, the value of which appears to equal 0xC0000005 which I think indicates a `STATUS_ACCESS_VIOLATION` according to https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55. ![image](/attachments/8789c50f-b215-44ee-808f-e7e7f5341eb9) In the drawing tablet's software, this exception only occurs if I actually connect the tablet to my PC, whereas Blender crashes even when the tablet is not connected. Currently, if I don't actually need my tablet, I'm working around the issue by starting Blender headless, changing the Tablet API setting to Windows Ink, and then starting Blender normally. I have already tried updating the drivers for my tablet to the newest version and it made no difference. If I start Blender with `--debug-wintab`, all that's printed is: ``` PS D:\Downloads\temp\blender-4.0.0-alpha+main.dd9a92785acc-windows.amd64-release> .\blender.exe --debug-wintab Read prefs: "C:\Users\Thomas\AppData\Roaming\Blender Foundation\Blender\4.0\config\userpref.blend" Loading Wintab for window 00000000000910C4 PS D:\Downloads\temp\blender-4.0.0-alpha+main.dd9a92785acc-windows.amd64-release> ``` Every version of Blender I've tried between 2.79 and 4.0.0a crashes unless I have the Tablet API set to `Windows Ink`. I don't know the specifics of how Wintab is handled, but could it be possible to either catch the exception in `WTOpen` and allow Blender to continue loading, or to check for a connected tablet before attempting to call `WTOpen`, similar to what my tablet's software appears to be doing? **Exact steps for others to reproduce the error** Unfortunately, Wintab getting into this erroneous state where it crashes in `WTOpen` occurs too rarely for me to figure out how to reproduce it and I'm not even sure if it's Blender that is causing it to get into this state in the first place.

image.png

3.4 KiB

Thomas Barlow added the

labels 2023-08-15 23:22:00 +02:00

Thomas Barlow commented

2023-08-15 23:35:00 +02:00

While I was typing up this issue, Wintab somehow managed to fix its erroneous state, which is the first time it's happened without me having to restart my PC.

The only things I can think of that I was doing was that I connected my drawing tablet and ran the wtinfo and wtcapt diagnostic utilities a few times.

While I was typing up this issue, Wintab somehow managed to fix its erroneous state, which is the first time it's happened without me having to restart my PC. The only things I can think of that I was doing was that I connected my drawing tablet and ran the [`wtinfo` and `wtcapt` diagnostic utilities](https://developer-support.wacom.com/hc/en-us/articles/9354461019927-Wintab-diagnostic) a few times.

YimingWu commented

2023-08-16 04:06:12 +02:00

I'm not sure about your setup, but could it be that some program is grabbing this tablet input exclusively?

From the code it looks like blender uses the typical wintab initialization process that's basically the same as wacom wintab example.

Do you have other programs that uses wintab encounter this issue? (like krita, photoshop etc)

Maybe it's a good idea to report this to Huion as well.

I'm not sure about your setup, but could it be that some program is grabbing this tablet input exclusively? From the code it looks like blender uses the typical wintab initialization process that's basically the same as [wacom wintab example](https://github.com/Wacom-Developer/wacom-device-kit-windows/tree/master/Wintab%20ScribbleDemo). Do you have other programs that uses wintab encounter this issue? (like krita, photoshop etc) Maybe it's a good idea to report this to Huion as well.

YimingWu commented

2023-08-16 04:18:00 +02:00

Found another similar issue reported in Godot as well, suspect the issue being on the driver side.

Found another similar issue reported in [Godot](https://github.com/godotengine/godot/issues/49018) as well, suspect the issue being on the driver side.

Germano Cavalcante added the

Platform

Windows

label 2023-08-16 21:55:20 +02:00

Pratik Borhade commented

2023-09-05 09:08:53 +02:00

@Mysteryem hi, still encountering crashes?

I'm not sure about your setup, but could it be that some program is grabbing this tablet input exclusively?

Any updates on this? :)

Found another similar issue reported in Godot as well,

Looks related

@Mysteryem hi, still encountering crashes? > I'm not sure about your setup, but could it be that some program is grabbing this tablet input exclusively? Any updates on this? :) > Found another similar issue reported in Godot as well, Looks related

Pratik Borhade added

Status

Needs Information from User

and removed

Status

Needs Triage

labels 2023-09-05 09:09:02 +02:00

YimingWu commented

2023-09-06 05:18:41 +02:00

From what I can tell there's not much updates on the wintab/godot side. We probably have to pass it on as is...

From what I can tell there's not much updates on the wintab/godot side. We _probably_ have to pass it on as is...

Thomas Barlow commented

2023-09-06 16:44:28 +02:00

Do you have other programs that uses wintab encounter this issue? (like krita, photoshop etc)

As far as I'm aware, Blender is the only program I'm using that uses wintab.

@Mysteryem hi, still encountering crashes?

I've had Blender's tablet API set to Windows Ink to avoid crashes. I've set it back to Automatic and will update when crashing starts again.

I have krita installed and know it works with my tablet, so I'll see whether it works when wintab is in the state that crashes Blender.

> Do you have other programs that uses wintab encounter this issue? (like krita, photoshop etc) As far as I'm aware, Blender is the only program I'm using that uses wintab. > @Mysteryem hi, still encountering crashes? I've had Blender's tablet API set to Windows Ink to avoid crashes. I've set it back to Automatic and will update when crashing starts again. I have krita installed and know it works with my tablet, so I'll see whether it works when wintab is in the state that crashes Blender.

YimingWu commented

2023-09-07 05:45:00 +02:00

@Mysteryem I think almost all program uses wintab before windows ink is a thing and it keeps that way since windows ink has some annoying stuff like initial stroke delays which is very hard to mitigate especially for drawing and stuff.

so I'll see whether it works when wintab is in the state that crashes Blender.

Yes, please do.

@Mysteryem I think almost all program uses wintab before windows ink is a thing and it keeps that way since windows ink has some annoying stuff like initial stroke delays which is very hard to mitigate especially for drawing and stuff. > so I'll see whether it works when wintab is in the state that crashes Blender. Yes, please do.

Thomas Barlow commented

2023-09-22 02:24:02 +02:00

Ok, Krita doesn't fare any better, it instantly closes and only manages to log "KRITA DID NOT CLOSE CORRECTLY" and nothing else.

The only thing possibly of note about how the bad wintab state started this time was that I was running a backup of the hard disk Blender is installed on at the time, so Blender took a long time to load.

Opened Blender (took quite a while because of the backup running in the background)
Everything appeared to be OK
Did File > Import > FBX to open the importer window
Blender closed
Blender no longer starts

But in good news, I can confirm the that running wtcapt.exe fixes the bad state, allowing Blender/Krita to start again. The only thing that stands out to me about wtcapt compared to Blender is that it uses WTOpenW rather than Blender's use of WTOpenA.

Ok, Krita doesn't fare any better, it instantly closes and only manages to log "KRITA DID NOT CLOSE CORRECTLY" and nothing else. The only thing possibly of note about how the bad wintab state started this time was that I was running a backup of the hard disk Blender is installed on at the time, so Blender took a long time to load. 1) Opened Blender (took quite a while because of the backup running in the background) 2) Everything appeared to be OK 3) Did `File` > `Import` > `FBX` to open the importer window 4) Blender closed 5) Blender no longer starts But in good news, I can confirm the that running [`wtcapt.exe`](https://developer-support.wacom.com/hc/en-us/articles/9354461019927-Wintab-diagnostic) fixes the bad state, allowing Blender/Krita to start again. The only thing that stands out to me about `wtcapt` compared to Blender is that it uses `WTOpenW` rather than Blender's use of `WTOpenA`.

YimingWu commented

2023-09-22 04:35:34 +02:00

Interesting... So do you happened to have any directory name that has non-ascii characters in the path of blender/wacom/huion driver or maybe ${PATH}? Typically for win32 APIs the A/W is left out for compiler to decide based on whether it's using wide string during compilation, if forcibly specify A version then it might have problem with strings that contains non-ascii characters.

Interesting... So do you happened to have any directory name that has non-ascii characters in the path of blender/wacom/huion driver or maybe `${PATH}`? Typically for win32 APIs the `A/W` is left out for compiler to decide based on whether it's using wide string during compilation, if forcibly specify `A` version then it might have problem with strings that contains non-ascii characters.

Thomas Barlow referenced this issue

2023-12-15 02:20:54 +01:00

Crashing when accessing file system from various features. #116095

Germano Cavalcante referenced this issue

2023-12-27 22:01:11 +01:00

Crashing when accessing file system from various features. #116095

Pratik Borhade referenced this issue

2024-02-07 07:22:07 +01:00

Crash while attempting to use the file save dialog window #117923

~~Germano Cavalcante referenced this issue 2024-04-03 20:01:53 +02:00~~

Pressure sensitivity disappears after closing the Preferences window with Parblo A610plus tablet #120226

Sign in to join this conversation.