x64 Blender Crashes on startup - Graphics tablet Access Violation #39825

New Issue

William Benn · 2014-04-21T13:09:52+02:00

William Benn commented

2014-04-21 13:09:52 +02:00

System Information
Windows 7 x64 Professional
AMD HD6970
Hanvon Art Master graphics tablet

Blender Version
Broken: Blender 2.69 r61343 (X64)

Short description of error
The graphics tablet fails to initialise which later causes an access violation to occur on Blender startup.

Exact steps for others to reproduce the error
Line 366 in GHOST_WindowWin32.cpp (In the constructor) fails so m_tabletData never gets initialised


if (fpWTOpen) {
	m_tablet = fpWTOpen(m_hWnd, &lc, TRUE);
	if (m_tablet) {
		m_tabletData = new GHOST_TabletData();
		m_tabletData->Active = GHOST_kTabletModeNone;
	}
}

Later on processWin32TabletInitEvent gets called in GHOST_WindowWin32.cpp and on line 1118 an access violation occurs because m_tabletData is still a null pointer at this stage:

m_tabletData->Active = GHOST_kTabletModeNone;

Adding a check into processWin32TabletInitEvent to see if m_tabletData has been initialised first and blender starts and seems to work ok. This issue isn't occuring on 32bit versions of Blender as fpWTOpen succeeds and subsequently m_tabletData gets initialised ok. I tried uploading a 7zipped dmp file (45mb packed / 350mb unpacked) but it said it exceeded the upload storage limit so you can download it from my OneDrive if you want: https://onedrive.live.com/redir?resid=3A353581A2695157%211927

**System Information** Windows 7 x64 Professional AMD HD6970 Hanvon Art Master graphics tablet **Blender Version** Broken: Blender 2.69 r61343 (X64) **Short description of error** The graphics tablet fails to initialise which later causes an access violation to occur on Blender startup. **Exact steps for others to reproduce the error** Line 366 in GHOST_WindowWin32.cpp (In the constructor) fails so m_tabletData never gets initialised ``` if (fpWTOpen) { m_tablet = fpWTOpen(m_hWnd, &lc, TRUE); if (m_tablet) { m_tabletData = new GHOST_TabletData(); m_tabletData->Active = GHOST_kTabletModeNone; } } ``` Later on processWin32TabletInitEvent gets called in GHOST_WindowWin32.cpp and on line 1118 an access violation occurs because m_tabletData is still a null pointer at this stage: ``` m_tabletData->Active = GHOST_kTabletModeNone; ``` Adding a check into processWin32TabletInitEvent to see if m_tabletData has been initialised first and blender starts and seems to work ok. This issue isn't occuring on 32bit versions of Blender as fpWTOpen succeeds and subsequently m_tabletData gets initialised ok. I tried uploading a 7zipped dmp file (45mb packed / 350mb unpacked) but it said it exceeded the upload storage limit so you can download it from my OneDrive if you want: https://onedrive.live.com/redir?resid=3A353581A2695157%211927

William Benn commented

2014-04-21 13:09:52 +02:00

Changed status to: 'Open'

William Benn commented

2014-04-21 13:09:52 +02:00

Added subscriber: @BovineCreature

Bastien Montagne commented

2014-04-23 16:56:32 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2014-04-23 16:56:32 +02:00

Some windows dev around? ;)

Juergen Herrmann self-assigned this 2014-04-29 10:26:35 +02:00

Juergen Herrmann commented

2014-04-29 10:26:35 +02:00

I'll look into this ;)

Juergen Herrmann commented

2014-04-29 10:41:19 +02:00

This behaviour is strange.
m_tabletData is initiallized in the constructor of the window.
Did you compile blender yourself?
If yes: Did you build it with WITH_CXX_GUARDEDALLOC?

This behaviour is strange. m_tabletData is initiallized in the constructor of the window. Did you compile blender yourself? If yes: Did you build it with WITH_CXX_GUARDEDALLOC?

William Benn commented

2014-04-29 20:28:03 +02:00

Yeah, I built it myself but not with "WITH_CXX_GUARDEDALLOC". Although I've just tried building it with that and it still gives the same issue.

It's still only being set to null in the constructor though isn't it? fpWTOpen appears to return null if the tablet context could not opened so maybe m_tablet needs to be checked that it isn't null in processWin32TabletInitEvent to prevent referencing the m_tabletData->Active member on the null value.

There could be an overflow occurring somewhere though, as I've noticed that the name of the tablet is retrieved fine in the fpWTInfo call in the 32bit version but just gets filled with garbage in the 64bit version although in both cases it claims it needs a 172byte buffer to store the data in.

Yeah, I built it myself but not with "WITH_CXX_GUARDEDALLOC". Although I've just tried building it with that and it still gives the same issue. It's still only being set to null in the constructor though isn't it? fpWTOpen appears to return null if the tablet context could not opened so maybe m_tablet needs to be checked that it isn't null in processWin32TabletInitEvent to prevent referencing the m_tabletData->Active member on the null value. There could be an overflow occurring somewhere though, as I've noticed that the name of the tablet is retrieved fine in the fpWTInfo call in the 32bit version but just gets filled with garbage in the 64bit version although in both cases it claims it needs a 172byte buffer to store the data in.

Juergen Herrmann commented

2014-04-30 10:21:38 +02:00

It could be an issue with the drivers of the Tablet. But crashing is not an option here.
I am still trying to find the cause of this but it's really hard because I don't have the hardware to really test this. With my Wacom Tablet everything works fine.

Just adding a if(m_tablet) would prevent the crash but it doesn't remove the root cause of this.

It could be an issue with the drivers of the Tablet. But crashing is not an option here. I am still trying to find the cause of this but it's really hard because I don't have the hardware to really test this. With my Wacom Tablet everything works fine. Just adding a if(m_tablet) would prevent the crash but it doesn't remove the root cause of this.

Fazekas Laszlo commented

2014-05-01 20:59:05 +02:00

Added subscriber: @totoro-4

Fazekas Laszlo commented

2014-05-01 20:59:05 +02:00

Maybe this worth a try: I've opened the context this way in my another program:

		// Get default context information
		fpWTInfo(WTI_DEFSYSCTX, 0, &lc);

		// Open the context
		lc.lcPktData = PACKETDATA;
		lc.lcPktMode = PACKETMODE;
		lc.lcOptions |= CXO_MESSAGES;
		lc.lcMoveMask= PACKETDATA;

Maybe this worth a try: I've opened the context this way in my another program: // Get default context information fpWTInfo(WTI_DEFSYSCTX, 0, &lc); // Open the context lc.lcPktData = PACKETDATA; lc.lcPktMode = PACKETMODE; lc.lcOptions |= CXO_MESSAGES; lc.lcMoveMask= PACKETDATA;

William Benn commented

2014-05-02 19:25:37 +02:00

Cheers, I've given that a go but unfortunately it still fails to initialise the graphics tablet context. Yeah I can imagine it'll be difficult to replicate without the tablet itself. I'll have a play with it over the bank holiday weekend; see if I can get the context to open ok.

Fazekas Laszlo commented

2014-05-02 19:35:09 +02:00

Just an idea: is it working with Gimp? If so, we can compare the Gimp source with Blender...

William Benn commented

2014-05-02 19:39:09 +02:00

Ah good plan; I'll gave that a go later this evening. I know that it works in the x64 version of Photoshop CS6 which appears to use WinTab too from a quick google search.

William Benn commented

2014-05-02 22:59:38 +02:00

Ok, so I tried GIMP which starts ok but the pressure sensitivity would not work. Going back to Photoshop CS6 x64 it turns out the pressure sensitivity doesn't work in that either, I must have been running the 32bit version before. So it looks like it is a driver issue relating to the trouble creating the context.

I've gone back to the Hanvon website and just tried using some drivers which apparently should only work with their newer model of tablets but those have now appeared to fix any issues creating the context in x64 versions. Pressure sensitivity now works in GIMP, Photoshop CS6 x64 and Blender x64 now starts fine.

So really I suppose in the cases where Blender can't create the tablet context it should perhaps just give up / log something and then startup with just mouse support like GIMP / Photoshop did to avoid the silent crash to the user.

Ok, so I tried GIMP which starts ok but the pressure sensitivity would not work. Going back to Photoshop CS6 x64 it turns out the pressure sensitivity doesn't work in that either, I must have been running the 32bit version before. So it looks like it is a driver issue relating to the trouble creating the context. I've gone back to the Hanvon website and just tried using some drivers which apparently should only work with their newer model of tablets but those have now appeared to fix any issues creating the context in x64 versions. Pressure sensitivity now works in GIMP, Photoshop CS6 x64 and Blender x64 now starts fine. So really I suppose in the cases where Blender can't create the tablet context it should perhaps just give up / log something and then startup with just mouse support like GIMP / Photoshop did to avoid the silent crash to the user.

Campbell Barton commented

2014-07-01 07:25:19 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2014-07-01 07:25:19 +02:00

I think this fixes it but I can't verify it.

   diff --git a/intern/ghost/intern/GHOST_WindowWin32.cpp b/intern/ghost/intern/GHOST_WindowWin32.cpp
   index 8436e3b..dacdb37 100644

     - a/intern/ghost/intern/GHOST_WindowWin32.cpp

   +++ b/intern/ghost/intern/GHOST_WindowWin32.cpp
   @@ -1102,7 +1102,7 @@ GHOST_TSuccess GHOST_WindowWin32::setWindowCursorShape(GHOST_TStandardCursor cur
    
    void GHOST_WindowWin32::processWin32TabletInitEvent()
    {

 - if (m_wintab) {

   +	if (m_wintab && m_tablet) {
    		GHOST_WIN32_WTInfo fpWTInfo = (GHOST_WIN32_WTInfo) ::GetProcAddress(m_wintab, "WTInfoA");
    
    		// let's see if we can initialize tablet here

The case where only some of the tablet vars are initialized isn't clear exactly how it should work correct.
But depending on m_tablet seems reasonable.

I think this fixes it but I can't verify it. ``` diff --git a/intern/ghost/intern/GHOST_WindowWin32.cpp b/intern/ghost/intern/GHOST_WindowWin32.cpp index 8436e3b..dacdb37 100644 ``` - a/intern/ghost/intern/GHOST_WindowWin32.cpp ``` +++ b/intern/ghost/intern/GHOST_WindowWin32.cpp @@ -1102,7 +1102,7 @@ GHOST_TSuccess GHOST_WindowWin32::setWindowCursorShape(GHOST_TStandardCursor cur void GHOST_WindowWin32::processWin32TabletInitEvent() { ``` - if (m_wintab) { ``` + if (m_wintab && m_tablet) { GHOST_WIN32_WTInfo fpWTInfo = (GHOST_WIN32_WTInfo) ::GetProcAddress(m_wintab, "WTInfoA"); // let's see if we can initialize tablet here ``` The case where only some of the tablet vars are initialized isn't clear exactly how it should work correct. But depending on `m_tablet` seems reasonable.

Fazekas Laszlo commented

2014-07-01 21:16:58 +02:00

@ideasman42: I can't try your solution (I've Linux), but it seems good.

It's the same but perhaps safer if you check m_tabletData directly instead of m_tablet, like elsewhere in the file.

@ideasman42: I can't try your solution (I've Linux), but it seems good. It's the same but perhaps safer if you check m_tabletData directly instead of m_tablet, like elsewhere in the file.

William Benn commented

2014-07-01 22:16:35 +02:00

Given it a go with both:

 if (m_wintab && m_tablet) {

and

if (m_wintab && m_tabletData) {

Either one prevents the crash from occurring; tried it again with just if (m_wintab) as a sanity check and the crash does happen again. So either solution looks good.

Given it a go with both: ``` if (m_wintab && m_tablet) { ``` and ``` if (m_wintab && m_tabletData) { ``` Either one prevents the crash from occurring; tried it again with just if (m_wintab) as a sanity check and the crash does happen again. So either solution looks good.

blender-admin commented

2014-07-03 08:33:47 +02:00

This issue was referenced by d5297b6283

This issue was referenced by d5297b62834d629600c2d23582b237bb23f5bcd9

Campbell Barton commented

2014-07-03 08:34:51 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2014-07-03 08:34:51 +02:00

Campbell Barton commented

2014-07-03 08:34:51 +02:00

Closed by commit d5297b6283.

Closed by commit d5297b6283.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

x64 Blender Crashes on startup - Graphics tablet Access Violation #39825