It be nice if future updates to /extern were treated as if they were lib updates (which they are) and have the platform teams atleast give these things a look over.

It's not that tricky, the check libraries call will actually grab the libs from svn if they don't exist, so if you move the update sources call after the check libraries call, you can reasonably assume the libs have been checked out and python should exist. (but checking for it wouldn't hurt)

The 2016 versions do, the 2015 version you have is gcn 1.2

Guessing you have been unpacking daily builds of blender on top of the previous version?

I did, but other things came up, never finished/published the patch.

Thanks for reporting back in detail what caused the issue!

Seems ok here, can you try starting blender with the blender_debug_log.cmd batch file located in the blender folder and attach the log files it produces?

The few times i have interacted with people asking about the VFX Platform, it was always these things

Can't reproduce with latest master.

It has come up with the fracture modifier guys, hence i figured i'd document it.

Did some fixes so it at-least builds now, However....

Bug report page clearly states

The windows libs have been added to SVN.

Fixed debug configuration missing the registry, left it for win32 since it's unknown how other platforms deal with this

Retry, fixing last update

• USD/Win: Copy usd registry for debug builds as well

Yeah i have noticed in the past as well, but was never able to repro it reliably, it was always one of those 'heh , weird'-once in a while things, with @Ruslan (rs2128) 's instructions i got it on my 4th try

We dropped support for 32 bit builds, so the libraries are no longer available.

Couple of things, i can't go back in time, there is no re-issuing the installers for 2.7x or 2.80.

That's how it always has worked, I'm not saying i agree with it, but that how it has worked for all the installers we have done for the 2.7x series.

I'm not seeing any mention of settings of appdata in that post?

landed in rB64b092974c71

Forgot to mention it in the commit message

Given there is a lib update in the pipeline, i'd rather get this out of the way sooner rather than later, not sure how to link this to T67184 beyond namedropping it.

Looks like a lighttpd error, perhaps relevant?

@Sergey Sharybin (sergey) as the local phab guru mind taking a peek here?

it's ok until the %0A then it http 400's

Ideally python would not be looking at anything outside it's own folder, and should leave other pythons on the system alone, If someone can talk me into re-creating the conditions that @Robert (rob0407) was having did i'd be happy to take a stab at this

It could be, but the batch file i made you run temporary reset the PYTHONPATH environment variable that it generally uses to find 'the wrong python' so yeah i'm kinda stumped here,

was this the .msi installer or the .zip?

does it work when you start blender using the blender_debug_log.cmd batch file located in your blender folder?

actually i take that back,it's tagging on -fno-sanitize=vptr to the cflags, which msvc doesn't like, WITH_COMPILER_ASAN should only be on when we build with clang.

Once small change needed, beyond that lgtm.

The internal variable names in 2017 are slightly different _Tss_mutex (2017) vs g_tss_mutex (2019), but the crash is essentially the same, i filed a ticket with ms since it doesn't really feel all that blender related, we'll see what they think about this.

managed to extract a minimal example showcasing the issue without the need for blender/USD.

And i stand by that statement! However if you feel like this isn't gonna work out, and bail on it, be sure to un-assign your self so someone else can have a go at this one

Looks like a file being written to your temp folder is having issues, I'm not entirely sure why it is unhappy, but there's a couple of things you can try (and i fully admit, i'm just throwing stuff at the wall here seeing if anything sticks)

On reproduction : originally this was found on the USD branch, I can supply the debug libs for this so you can build/see it for your self.
It's as easy as make a build, drop in the softwaregl opengl32.dll and boom it goes.

separated out the delay load for master in D5387

removed delayloading

lists an 8.17 driver, he's currently on 8.15 , may just be enough to get him there.

you go to the toshiba website, and look for support for the device you bought, they generally offer driver updates specialized for their hardware on the website.

Driver linked should have worked, try to see if toshiba has updated drivers for your computer.

can you post a screenshot of the first tab of GPU-Z ?

Not sure how comfortable you are with the command prompt, but can you try running from the command prompt either

In D5359#121423, @Sybren A. Stüvel (sybren) wrote:

due to the use of thread_local in usd, i had to delay load opengl32 since when you use mesa it'll spin off a bunch of threads before the crt on the main thread is initialized leading to a crash due to uninitialized locks.

Can you add this to a comment in the file? That way this knowledge doesn't get lost.

can you see if there's a mini dump from around the time of the crash in c:\windows\minidump ?