I can't reproduce on an actual win7 machine, however blender ships on linux with a blender-softwaregl script in the blender folder, try starting blender with that and see if that eliminates the problem.

1. Please do not triage tickets your self, we'll change the status to confirmed when we confirmed the problem.
2. for future posts , if you go to File->External Data->pack into blend, it'll pack the textures into the .blend file so you don't have to post all your textures as attachments. (and we don't have to go out and manually fix a bunch of textures)
3. I tried 2.78c and the latest from the buildbot at http://builder.blender.org and I can't seem to reproduce the problem, is it crashing while trying to render? or when you are in material view mode? what exactly are you doing when it crashes?

While this is the right place for blender bugs, we don't take any bugs on 3rd party addons, you'll have to sort this out with the baketool people.

While final image seems identical on windows, it does crash the blender at the end of the render, debug heap seems to imply it's a use after free bug, @Brecht Van Lommel (brecht) do you happen to have time to run F643176 through asan ? (and maybe comment on the other problems?)

I noticed the weird behavior of the u and v globals as well, but just as a sanity check, are you saying this file on mac renders identical rectangles?

Yeah this bug has dragged on long enough, I'll see if i can get my patch in an acceptable state this weekend, so we no longer have to guess why a card is failing

That's an opengl 2.1 card, so yes,

There's no data in this file, it's filled with 0's , blender is right to reject it.

it's rarely a good idea to drag up old closed tickets, this one had been closed for a year+ the other ticket you spammed 5+ years! In those cases it's usually better to start a new ticket,

I've noticed loading environment textures is incredibly slow with osl enabled, but it doesn't crash, just sits there for a while but eventually it'll get it together and starts rendering...

@Mike Erwin (merwin) poke, can we give this somewhat of a priority? currently blender 2.8 will only start on windows with cards with ogl 4.5 , seems a little steep.....

while the crash is annoying and we should give a better message about what's wrong, your video card only supports opengl 3.1 where 3.3 is the minimum required for blender 2.8.

Reduce your tile size in the render settings, should fix the issue.

Can you check your windows event log for any reports of event ID 4101 around the time that blender crashes?

Can we then disable this test until the legacy despgraph is no longer the default?

In D2716#63846, @Joerg Mueller (nexyon) wrote:

Thanks, I'll have a look at that. Can you show me the errors that you get with Python? For fftw3 it is not enough to enable it with cmake (WITH_FFTW3)?

Also if an unmodified audaspace works, could we possibly take it out of extern and move it to install_deps.sh / svn like most other externals?

Currently doesn't build on windows, needs a little work in the parts where it looks for both python and fftw3 (there may be other things, but for now this is where it is most unhappy)

Any of the 2.8 builds for your platform would do

Could still be we're feeding the ogl driver bad data and it's wigging out because of that, most of the opengl got quite some rework in 2.8, try a 2.8 build and see if you can make it misbehave.

analysis for the dump @Alexandre LAB (geeks) posted , looks like a stack overflow in the nvidia driver...

eeve is blender 2.8 not blender 2.79

This got fixed last week after we made the test build, should be fixed in a nightly from https://builder.blender.org

I'm not sure what you are running ? Clay, Eeve etc are 2.8 engines, not 2.79? Please clarify the problem with some screenshots of what is missing?

correct.

GT 120 is an opengl 3.0 card, for 2.8 you need at-least a 3.3 card

T45940 might also be relevant

try the .zip instead of the msi

That's just a warning, you can safely ignore it, that being said, you have not supplied enough information for us to actually determine if this is a bug or not

Known issue with intel drivers, the ticket linked should have a version number of the drivers that'll work.

I fixed the windows build, the next nightly build should be working.

In T51754#439724, @Nicholas Wolf (nicwolf) wrote:

Windows: Crashes. Unsure of the cause, will investigate.

I did some testing as well, this only seems to crash in the msvc2013 release build, debug build is fine, so are the msvc2015 builds. Have to look further into this

can't reproduce either, try starting blender with the --factory-startup commandline option and see that resolves the problem.

this doesn't look like a function that will be called enough to justify the inline? so short term i suggest just removing the keyword so things get building again, for future things you might want to inline just toss a

#ifdef _MSV_VER 
#define inline __inline
#endif

^^^ live typed in this ticket, no license issues

You're absolutely correct ,it works fine when i replace the monkeys with a simple plane! thanks for your insight!

Might be less icky than expected, this patch solves the issue, but needs some massive cleanup, (i pretty much copied clone_window from a different file... needs to be solved better)

@Mike Erwin (merwin) , looked a little further into this, it's an icky problem, and we need to find a different way to scan for the opengl context we want to work with.

Your gpu is too old, and doesn't support the minimum opengl version required for blender 2.8,

@Joel Godin (FloridaJo), please triage a little bit more careful in the future, just because the user is on windows, doesn't mean it's a windows specific issue.

you go to the http://builder.blender.org website, and click the download link?

Testing doesn't ship with release builds, but it is included in nightly builds from builder.blender.org

@Sergey Sharybin (sergey) / @Bastien Montagne (mont29) is there any chance this can still get squeezed into 2.79?

This fixes T51649, tested, works wonderfully

This is a gcn 1.0 card, which is no longer supported, see T51659 for details

clearly not a bug, glad to hear you got it sorted though

Also check out Window->Show console, it might display some diagnostics information there

Then it's definitely using the CPU , try a nightly build from https://builder.blender.org/download/ also be sure to install the latest drivers from nvidia, win10 is known to push shoddy drivers over windows update lately

When it's rendering, do you have a single tile being rendered at the same time or multiple?

This is a known intel driver issue, the linked ticket should have a driver version that'll work.

While it solved my problem, i agree a generic solution beats a quick hack.

whitespace fix

Try installing the latest drivers from the nvidia website, the ones coming from windows update have caused issues like these before.

so problem is fixed?

@Brecht Van Lommel (brecht), looks like you updated python to 3.5.3 but didn't rebuild numpy , mind taking a quick peek here?

Cleanup looks all-right, doesn't break any tests, be sure not to commit those new line changes, beyond that lgtm

so 2.78c is fine, but the builds from builder.blender.org crash?

anaconda is open data science platform ( https://www.continuum.io/downloads ) that also uses python, but sometimes their setup interferes with our libraries.

there's a command line switch for that , blender --factory-startup

Strange.... if you grab a nightly from https://builder.blender.org/download/ same thing?

it's an internal path inside an alembic file, we should not impose any OS related restrictions to that in the first place?