Page 1 of 2 12 LastLast
Results 1 to 15 of 24

Thread: Newish buggy

  1. #1
    Curmudgeon in Training Ma3rk's Avatar
    Join Date
    Mar 2003
    Location
    Near Beaverton, OR
    Posts
    1,541

    Newish buggy

    This just got reported officially, but thought I'd mention it here too as I've not seen anything along these lines.

    100% repeatable.

    Start layout.

    From the Surface Editor Panel, Open up the Preset Shelf.

    Minimize the Preset Window.

    File your Crash Report.

    It's odd that I never saw this before. I've been relegated to a laptop for the past couple months so not much screen territory. I guess I've been closing the window instead of minimizing all this time, which for now is the work around I guess if you don't have a 2nd screen.
    "Never be a cat in a cartoon. Never." Chief Wiggum

  2. #2
    No issues here.
    Tim Parsons
    Technical Designer
    Sauder Woodworking Co.

    http://www.sauder.com

  3. #3
    Curmudgeon in Training Ma3rk's Avatar
    Join Date
    Mar 2003
    Location
    Near Beaverton, OR
    Posts
    1,541
    Quote Originally Posted by Tim Parsons View Post
    No issues here.
    Well, your obviously not doin' it right!

    I initially reported this to a certain 3rd party developer & he immediately had the same results as me, so now wondering what the difference is?

    2019.1.3, Win10 Pro. Current nVidia drivers.
    "Never be a cat in a cartoon. Never." Chief Wiggum

  4. #4
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,713
    Quote Originally Posted by Ma3rk View Post
    2019.1.3, Win10 Pro. Current nVidia drivers.
    Might want to re-test in 2019.1.4 (aka "current LW"). Steps as described don't cause crash with LW2019.1.4 here either.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  5. #5
    Curmudgeon in Training Ma3rk's Avatar
    Join Date
    Mar 2003
    Location
    Near Beaverton, OR
    Posts
    1,541
    Quote Originally Posted by jwiede View Post
    Might want to re-test in 2019.1.4 (aka "current LW"). Steps as described don't cause crash with LW2019.1.4 here either.
    Ya. Think I'll give that a try.
    "Never be a cat in a cartoon. Never." Chief Wiggum

  6. #6
    Curmudgeon in Training Ma3rk's Avatar
    Join Date
    Mar 2003
    Location
    Near Beaverton, OR
    Posts
    1,541
    Nope, still the same issue with 2019.1.4.

    Will poke around some more & maybe file an updated report.
    "Never be a cat in a cartoon. Never." Chief Wiggum

  7. #7
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,825
    Reproducible for me every time on LW2019.1.4 using the steps described, both on my laptop and tower PC. Attached is the DebugDiag text file, which might help LWDG find / fix the problem.

    Layout__PID__15916__Date__11_29_2019__Time_10_27_20PM__711__Log.txt

    I'm running Windows 7.

    mTp

  8. #8
    Curmudgeon in Training Ma3rk's Avatar
    Join Date
    Mar 2003
    Location
    Near Beaverton, OR
    Posts
    1,541
    Well, fun. Wonder what the common element is?
    "Never be a cat in a cartoon. Never." Chief Wiggum

  9. #9
    Registered User
    Join Date
    Aug 2017
    Location
    Slo
    Posts
    81
    Win7 and Quadro, works OK in 2018.0.7, crashes in 2019.1.4.

  10. #10
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,713
    Quote Originally Posted by MonroePoteet View Post
    Reproducible for me every time on LW2019.1.4 using the steps described, both on my laptop and tower PC. Attached is the DebugDiag text file, which might help LWDG find / fix the problem.

    Layout__PID__15916__Date__11_29_2019__Time_10_27_20PM__711__Log.txt

    I'm running Windows 7.

    mTp
    Seems to be a conflict between dwrite.dll (DirectWrite), possibly ShellFolderFix DLL, and LW. The exception indicates an access violation of some sort, and it happening in dwrite (and prior stack) suggests something about window rendering (and/or glyph rendering). That it happened after a bunch of ShellFolderFix API accesses might be nothing, or it might be some pathological interaction between its operation and Dwrite.dll... or none of the above.

    Ma3rk, are you using ShellFolderFix as well? If you could generate the same sort of log as Monroe, that'd help debug it.

    Anyone using ShellFolderFix might want to try disabling it to see if that solves the issue.
    Last edited by jwiede; 11-30-2019 at 05:28 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  11. #11
    Curmudgeon in Training Ma3rk's Avatar
    Join Date
    Mar 2003
    Location
    Near Beaverton, OR
    Posts
    1,541
    Quote Originally Posted by jwiede View Post
    Seems to be a conflict between dwrite.dll (DirectWrite), possibly ShellFolderFix DLL, and LW. The exception indicates an access violation of some sort, and it happening in dwrite (and prior stack) suggests something about window rendering (and/or glyph rendering). That it happened after a bunch of ShellFolderFix API accesses might be nothing, or it might be some pathological interaction between its operation and Dwrite.dll... or none of the above.
    Ma3rk, are you using ShellFolderFix as well? If you could generate the same sort of log as Monroe, that'd help debug it.

    Not that I'm aware. Where would I check?

    The error generates a dmp that gets attached to the report. Should be able to make or find what he attached.

    Anyone using ShellFolderFix might want to try disabling it to see if that solves the issue.
    "Never be a cat in a cartoon. Never." Chief Wiggum

  12. #12
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,825
    No, disabling ShellFolderFix doesn't remedy the problem.

    After disabling ShellFolderFix, the stack for the thread that had the ACCVIO (Exception #: 0xC0000005) is identical with the stack with ShellFolderFix enabled. The new TXT file and the ACCVIO stack with ShellFolderFix disabled are included below.

    I don't see ShellFolderFix in any of the thread stacks in the original TXT file, but maybe I'm looking in the wrong place. All I see is the ShellFolderFix DLL being unloaded as the image is run down, but it isn't on any of the stacks.

    The culprit would seem to me to be one of the following (off the ACCVIO 0xC0000005 stack):

    Qt5Gui!QPainter::renderHints
    tools!ORastBlitCopyScaled+0xe6
    tools!ORastBlitCopy+0x53
    vizbrz!StartupColorSpacePresets+0x1347e
    vizbrz!StartupColorSpacePresets+0x12125

    I'd go look at the two offsets (0x12125 and 0x1347e) into vizbrz!StartupColorSpacePresets() in the .MAP file, look at the corresponding function calls to make sure all parameters being passed downward have been validated and have good defaults if they're missing.

    I'd guess tools!ORastBlitCopy() and tools!ORastBlitCopyScaled() are well-used & tested utility routines which are just using a bad parameter passed in from above (i.e. below them on the stack). I'd guess that tools!SeqSysStep+0x217 is a generic internal scheduling routine to do background work, such as redraw the display. So I think under some circumstances StartupColorSpacePresets() isn't creating the correct parameters for ORastBlitCopy().

    Of course, this is complete and total guesswork!

    mTp

    The new TXT file from DebugDiag with ShellFolderFix disabled / shut down: Layout__PID__14852__Date__11_30_2019__Time_10_04_45PM__838__Log.txt

    The crashing thread stack:

    Code:
    DetailID = 8
    	Count:    2
    	Exception #:  0XC0000005
    	Stack:        
    		Qt5Gui!QPainter::renderHints
    		tools!ORastBlitCopyScaled+0xe6
    		tools!ORastBlitCopy+0x53
    		vizbrz!StartupColorSpacePresets+0x1347e
    		vizbrz!StartupColorSpacePresets+0x12125
    		tools!SeqSysStep+0x217
    		tools!RedrawIdle+0x13e
    		tools!WManGetInput+0x246
    		Layout!MotionControllerGradContextDestroy+0x2ab2f
    		Layout!CreatePreviewWindow+0x42bb5
    		Layout!CreatePreviewWindow+0x42eba
    		Layout!GetHardwareSerialNumber+0xa23e
    		kernel32!BaseThreadInitThunk+0xd
    		ntdll!RtlUserThreadStart+0x21

  13. #13
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,713
    LW isn't exactly "defensive" in its handing of error states, to put it politely, so once "off the rails" it's common to see all sorts of cascading exceptions, etc. triggered.

    I'm still inclined towards exceptions 1 & 2 for a couple reasons: They're the first, they're similar in stack (if #1, thread 4148, were "expected" then the handler would catch and fix it, not hit it again as #2), and because apparently #1 or #2 triggered a second-chance exception later (#8). If I'm reading correctly, exception #8 is second-chance exception from prior thread exception (explicitly a "reaction" event, thus NOT root cause) -- second-chance is effectively just the OS taking notice and getting upset earlier thread exception (#1 or #2) wasn't caught, so debug code if present has a chance to dump memory.

    The others I'm inclined to believe are just cascading failures by the app "off the rails, and rolling free in the weeds" (in technical terms). But here too, little better than informed guestimates.

    Last edited by jwiede; 12-01-2019 at 03:28 AM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  14. #14
    Registered User
    Join Date
    Jan 2005
    Location
    Colorado Springs
    Posts
    1,825
    Yeah, without access to the source code (including maps), it's all guesswork for me. RE: parameter validation, handling error states, etc. there's always a problem with robust code being slow. At the inner loops (like the raster block transfers into graphics memory and the code directly feeding those routines), I can imagine error checking and parameter validation is fairly minimal to keep the performance up. When I've done high-performance development we've relied on in-depth code reviews beforehand and dump analysis after the fact to find-and-fix the root problems rather than implementing "slow" generalized error handling except when we *know* there will be unpredictable environmental issues.

    Anyway, hopefully someone will submit a bug with the TXT files and LWDG will spot the issue and fix it.

    mTp

  15. #15
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,713
    BTW, the issue is likely Windows-only -- it appears to occur in Windows-specific DLLs, and it's in an area that's highly platform-specific. Thus far I've been unable to reproduce it here on Mac LW, as well.

    Probably worth both of you filing reports along with your dump files.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •