Can't seem to repro, added some loopcuts to cylinder.000, seemed just peachy, could be a driver bug.

To check for that you can try dropping the opengl32.dll from here http://download.blender.org/ftp/sergey/softwaregl/win64/ into your blender folder and try again. (be sure to remove it when you're done testing, software opengl doesn't have the best performance)

I did this test last time. The result was a big freeze.

What I can not explain: why blender 2.75a works. Why 2.78 does not work. Same conditions of use for both versions.

Blender 2.75a:

• Modeling: OK
• Rexturing / Mapting under Cycles: OK

Blender 2.78 all versions and bluidbot:

• Modeling: Crahs (loop cut)
• Rexturing / Mapting under Cycles: OK

So it's not a driver bug. When this bug is when I add loop cut on an object in edit mode.

This is not a Blender Buildbot Project - removing.

Removing all project tags but BF Blender for until we now what actually causes the issue.

Please, let us handle the project tagging.

Ok

Its highly likely that this bug is specific to your hardware/driver configuration.
These kinds of display issues are often caused by OpenGL driver bugs.

While its possible a software error in Blender,
its worth checking if this functions correctly...

• After upgrading graphics card drivers.
• On a different system (with different hardware/drivers).
• Using a Software OpenGL renderer...
  • On Linux, Official releases come with blender-softwaregl
  • On MS-Windows: Downloading 'opengl32.dll' from download.blender.org/ftp/sergey/softwaregl and copying it so its located in the same directory as 'blender.exe' (make sure to grab the 64-bit version)

If this is a driver bug, or we can't link to this to an error in Blender's code,
the report may be closed as a driver error,
so please help us determine whether this is a bug in Blender or not.

Thank you for answering

In T50126#410105, @Aaron Carlisle (Blendify) wrote:

Its highly likely that this bug is specific to your hardware/driver configuration.
These kinds of display issues are often caused by OpenGL driver bugs.

It would seem that this may come from there. But why would it work perfectly with previous versions?

While its possible a software error in Blender,
its worth checking if this functions correctly...

• After upgrading graphics card drivers.

I upgraded to the latest NVidia drivers.

• On a different system (with different hardware/drivers).

Indeed, I have not tested on my laptop. But I do not think I'd do it until I'm sure it's OK level bug. Alas, when I see the todo bug list ...

• Using a Software OpenGL renderer...
  • On Linux, Official releases come with blender-softwaregl

Lost, I have no more Linux available to test.

• On MS-Windows: Downloading 'opengl32.dll' from download.blender.org/ftp/sergey/softwaregl and copying it so its located in the same directory as 'blender.exe' (make sure to grab the 64-bit version)

I tested this option. Big fat lag ... impossible to run Blender. It's as if you do shoot the scene and you have time to drink your coffee and read a good Shakespire same time!

If this is a driver bug, or we can't link to this to an error in Blender's code,
the report may be closed as a driver error,
so please help us determine whether this is a bug in Blender or not.

I maintain that Blender works in its previous versions. Since version 2.77, big concerns regardless of the version, not stable, stable or ongoing!

Please let me know what Blender is doing while I'm using it. This may be useful to see if it's not a "null point"

Sometimes it will fail to work on older hardware because Blender updates its code to new standards.
The 'opengl32.dll' is going to be slower because it runs the entire UI on the CPU and thus illuminating possible GPU issues.
It is critical that you wait through the lags and test. If you find that it still happens with the dll-file then we we know that it is a bug with Blender and will be willing to look more into this specific issue.
However, like what other people have said after testing leads me to believe that this is a hardware issue. If using the dll-file gives correct results then there is nothing we can do because the issue comes from your hardware.

Also you say that you are running windows 10 family but that does not exist https://en.wikipedia.org/wiki/Windows_10_editions So something seems wrong on your end.

Would this imply that the embedded version of OPEN-GL of my graphics cards is exceeded?

Is it wise to block the material yet not so old? Especially since others use versions even older than my cards?

To get back on the dll, this is far from being so obvious. What do we mean by "It's critical that you wait through the lags and test." ?

In addition, here is a view of the driver version used and up to date currently.

Thank you for bringing me these few answers.

I do not use any add-ons. I even prefer to use the basic configuration.

However, I have 2 questions.
1 / For tests, is it imperative to use the DLL?
2 / On Windows, how to have the console?

GTX 580 is a few years old but very capable GPU. It should be supported for 2.7x and even 2.8x

Try this with the latest Blender version:

Open command prompt (windows key, type "cmd").
Navigate to Blender's install location with the "cd" command. On my system it lives at
C:\Program Files\Blender Foundation\Blender>

type "blender --debug-gpu" to run it with extra OpenGL debugging.

For simplicity. I downloaded the latest version, unzipped as from the bluidbot.
I put the dll as requested and navigated with the command prompt.
Some returns now with attached files.

If it helps.

I am the author from the Ticket T50506, it works then I copy the opengl32.dll to the path from blender.exe.

But the blender is so slow that I can’t work with him, open the by pressing ctrl alt u need up to three second to open the menu.

This issue comes all from update to windows10 build 15014 from windows insider program in the fast ring.

I report that also to Microsoft other the insider program and the feedback hub

Michael

I do not have time to watch tonight. I'm trying to resume testing this weekend, probably Sunday.

Sorry to make you wait. Ok for the new test.

It's cool that there are ideas on W10 updates.

In T50126#413790, @Michael Calmbach (callicalli) wrote:

I am the author from the Ticket T50506, it works then I copy the opengl32.dll to the path from blender.exe.

But the blender is so slow that I can’t work with him, open the by pressing ctrl alt u need up to three second to open the menu.

This issue comes all from update to windows10 build 15014 from windows insider program in the fast ring.

I report that also to Microsoft other the insider program and the feedback hub

Michael

I just tried the ctrl + alt + u and nothing opened!

How did you do this operation?

I'm also getting a white screen except it's on startup. It doesn't seem to be a freeze or crash, as by clicking around in the white space I accidentally opened a link to blender.org. It seems GPU-related, as if I run with integrated graphics it works fine (if a little slow) but if I run with my 730m I get white screen. Drivers are latest.

Blender 2.78c fresh install
Windows 10 x64 insider preview
NVIDIA GeForce 730m

Good evening,

Finally a little time to do a bit of blender.

I attacked a mod, on which I place a smooth. I made a pre-rendered bam, Blender to stop working.

As usual, I have attached my report on the others.

I continued my investigations. I turn the SLi which can lead to lags. As a result, I always have the same error. This time, it happened during Ctrl + Z.
I would be very happy if you find out where this can come from.

History to unwind a little more. I loaded the benchs of Blender cycles. As I had first thought, it's during the modeling and more precisely when I manipulate the scene. Rotate / move object.

10 minutes of rendering without any particular problem. The ram held, the graphics cards also.

But what is that?

New error during modeling

Consider:
I changed the sound quality. This seems to have resolved the message from the startup screen. But it still crashes!

A turn under dxdiag report errors on a dll. As explained at the beginning.

I also looked at whether the Dll in question was in its proper place. Its good :

There, I can do nothing better.

There is hope that the concern is a little more isolated.

Hello,

Investigations continued.

I incriminate the audio through the DLL indicated above and in the report of errors. So I eliminated the sound in options such as:

I used the command line tool to start Blender. I discovered this:

I reinstalled the MV C ++ Redistributable (X64) and (X32) 2013 and 2013:

Let's add the file userperf.blend in relation to the following post (https://developer.blender.org/T44127 , https://developer.blender.org/T48027 and https://developer.blender.org/T30271):

I am moving more and more towards a concern python + dll. I hope this will help the community to resolve this concern.

Good luck

These error messages are harmless:

Failed to set 48000 Hz
<!> event has invalid window
Not freed memory blocks

So they're not related to the problem you're seeing.

Okay :)

I finished my tests with the .blend that crashes, I put it at your disposal.

There is no step type that is planted. On the other hand, this often happens during moving 3d objects in the scene to see during the viewport manupilation.

Simple example.

• Add a mesh.
• Switch to edit mode.
• Remove vertex.
• Put a subsurf -> crash.

Another example.

• Add a mesh.
• Switch to edit mode.
• Move a vertex point.
• Change the name of the object.
• Revert to edit mode -> crash.

But other steps can lead to crashing.

Hello

New tests and new crashes.

This time I was in the temp folder to find what happens.

Once again. There is no order. Place a cylinder, make a copy of some faces, extrude, make a subsurf, place one or two cuts, put a subdivision and make a spin ...

Operations somes all basic.

But if it can help the team, give as much information as possible.

I did not see any error in the ms-dos window. Which means that the crash happened somewhere unprecedented.

By dint of search, I found tracks. A priori many people are full of W10. I think that one of the tracks is here.

Hello,

Despite the return to a correct operation over several days. "Blender to stop working."

The video driver is up to date.

From there, I think the problem is difficult to flush out.

1/ place mesh plane
2/ edit mesh, add face, add vertex, extrude face...
3/ place modifier -> curve + array not applied
4/ move object in edit mod
5/ crash

I just got my hands on Blender's dump-crash.

It is very simple, crashes occur during edit mode.

Would not the concern be that the ctrl + r would cause a bad name for the vertex?

When windows closed, a null point occurred.

windows 10 has a future is auto re-install GPU driver but not mentioned.
You can download a driver from nvidia's home page, then re-install GPU driver again manually.
This could solve a lot of situation when run blender on windows 10.

Lost, I am up to date manually level graphics card driver.

On the other hand, found very interesting system info!

Good evening,

Is it possible that Windows 10 imposes its graphics driver instead of that of NVIDIA?

If so, it would explain that the nvoglv64.DLL dll crash because it is used by the Windows 10 driver.

That is the conclusion I have drawn from it.

For now, I'm back on the driver version of windows said "generic". But I do not think it has solved the problem.

Do you confirm this possibility?

In T50126#438020, @Alexandre LAB (geeks) wrote:

Is it possible that Windows 10 imposes its graphics driver instead of that of NVIDIA?

Not really, hardware companies (AMD, NV, Intel) make the OpenGL drivers on Windows.

Ok.

Can it come from the autosave?

I switched Blender to stand alone on a disk other than the system, I disabled the autosave. That seems to work. I look forward to seeing in the long run!

I still have the problem: blender has stopped working.

Certainly the autosave less, makes it happen a little later. I could work on it for several days.

On the other hand, I have a certainty. When it crashes, I'm in edit mode.

This is where we must look now.

Thanks to the team who will be able to resume the subject because it is important to know why the mode edit plant.

Other info, I have no error in the console at the time of crash.

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

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** The OS name list needs to be updated! Unknown Windows version: 10.0 ***
GetUrlPageData2 (WinHttp) failed: 12002.

FAULTING_IP: 
nvoglv64+fb5b78
00000000`68695b78 cd29            int     29h

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000068695b78 (nvoglv64+0x0000000000fb5b78)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000000007

CONTEXT:  0000000000000000 -- (.cxr 0x0;r)
rax=0000000000000001 rbx=0000000000000007 rcx=0000000000000007
rdx=0000003da29fe1d0 rsi=0000000000000000 rdi=00000239ad5a0078
rip=0000000068695b78 rsp=0000003da29fe1c0 rbp=0000000000000000
 r8=0000003da29fe1c0  r9=0000003da29fe1c8 r10=00007ffde35515c0
r11=0000003da29fe1b8 r12=0000000000000001 r13=0000000000000003
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
nvoglv64+0xfb5b78:
00000000`68695b78 cd29            int     29h

PROCESS_NAME:  blender.exe

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_PARAMETER1:  0000000000000007

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  blender.exe

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

FAULTING_THREAD:  00000000000020a4

BUGCHECK_STR:  APPLICATION_FAULT_FATAL_APP_EXIT_SEHOP

PRIMARY_PROBLEM_CLASS:  FATAL_APP_EXIT_SEHOP

DEFAULT_BUCKET_ID:  FATAL_APP_EXIT_SEHOP

IP_ON_HEAP:  00000239ad5a0078
The fault address in not in any loaded module, please check your build's rebase
log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module which may
contain the address if it were loaded.

FRAME_ONE_INVALID: 1

LAST_CONTROL_TRANSFER:  from 00000239ad5a0078 to 0000000068695b78

STACK_TEXT:  
0000003d`a29fe1c0 00000239`ad5a0078 : 00000000`00000003 00000000`00000003 00000000`00000007 00000000`00000007 : nvoglv64+0xfb5b78
0000003d`a29fe1c8 00000000`00000003 : 00000000`00000003 00000000`00000007 00000000`00000007 00000000`682bdb1d : 0x00000239`ad5a0078
0000003d`a29fe1d0 00000000`00000003 : 00000000`00000007 00000000`00000007 00000000`682bdb1d 00000239`ad5a0078 : 0x3
0000003d`a29fe1d8 00000000`00000007 : 00000000`00000007 00000000`682bdb1d 00000239`ad5a0078 00000000`6e760001 : 0x3
0000003d`a29fe1e0 00000000`00000007 : 00000000`682bdb1d 00000239`ad5a0078 00000000`6e760001 00000239`ad5a0000 : 0x7
0000003d`a29fe1e8 00000000`682bdb1d : 00000239`ad5a0078 00000000`6e760001 00000239`ad5a0000 00000000`c0000001 : 0x7
0000003d`a29fe1f0 00000239`ad5a0078 : 00000000`6e760001 00000239`ad5a0000 00000000`c0000001 00000000`00000000 : nvoglv64+0xbddb1d
0000003d`a29fe1f8 00000000`6e760001 : 00000239`ad5a0000 00000000`c0000001 00000000`00000000 0000003d`a29f0001 : 0x00000239`ad5a0078
0000003d`a29fe200 00000239`ad5a0000 : 00000000`c0000001 00000000`00000000 0000003d`a29f0001 00000000`00000000 : 0x6e760001
0000003d`a29fe208 00000000`c0000001 : 00000000`00000000 0000003d`a29f0001 00000000`00000000 0000003d`a29fe680 : 0x00000239`ad5a0000
0000003d`a29fe210 00000000`00000000 : 0000003d`a29f0001 00000000`00000000 0000003d`a29fe680 00000000`00000000 : 0xc0000001


STACK_COMMAND:  ~0s; .ecxr ; kb

FOLLOWUP_IP: 
nvoglv64+fb5b78
00000000`68695b78 cd29            int     29h

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  nvoglv64+fb5b78

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nvoglv64

IMAGE_NAME:  nvoglv64.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  58df0143

FAILURE_BUCKET_ID:  FATAL_APP_EXIT_SEHOP_c0000409_nvoglv64.dll!Unknown

BUCKET_ID:  APPLICATION_FAULT_FATAL_APP_EXIT_SEHOP_nvoglv64+fb5b78

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:fatal_app_exit_sehop_c0000409_nvoglv64.dll!unknown

FAILURE_ID_HASH:  {d66792de-d6a8-a656-51f9-8e20d92f7272}

Followup: MachineOwner

Ok for this information and thank you for the describe.

Now you have to do what?
Do I have to report this information back to NVIDIA?
Or should I wait for a fix in a particular build?

I'm waiting to see Blender work again.

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.

In T50126#441094, @LazyDodo (LazyDodo) wrote:

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.

It's possible. Especially since the 2.75 works. After, the 2.76, 2.77 and 2.78 causes crashes!

If I understand. So I have to take in the buildbot? But what version could contain a fix?

In any case I am ready to help you with the resolution.

Any of the 2.8 builds for your platform would do

Ok, so go for this version:

I'll keep you informed of the results.

Thanks

I think I can confirm this bug on my machine, I have a Geforce Gtx760 and in 2.78c I'm getting random crashes like the ones described here,
Loop cut then crash, Ctrl+z then crash, delete face or vertex then crash, as the creator of this bug ticket said, all the crashes happened in edit mode.

The most frustrating thing about this problem is that I can't seem to reproduce this problem with consistency, I can be modeling for some half an hour or an hour and nothing happens, and some times I load Blender and the first vertex I move in edit mode crashes the application, tho this is rare, most of times it crashes after I been working for at least half an hour or an hour.

Im working on windows10 and my drivers are up to date, I also have a two monitor setup one is a Samsung screen and the other is a Hybrid Cintiq.

In my command window, in debug mode, all I get is an error: EXCEPTION_ACCESS_VIOLATION at the end of the line, and the thing written previous to that is literally just the last action I did in blender that caused the crash, like a loop cut, or ctr+z

I haven't experimented with 2.8 but I might as well give it a shot, I will report my findings as well.