Exception in driver when writing to SSBO in loop

Writing to SSBO from computer shader for-loop causes driver exception in nvoglv64.dll. The shader to reproduce is

#version 430 core

layout ( local_size_x = 1, local_size_y = 1, local_size_z = 1 ) in;

layout ( std430, binding = 0 ) buffer Output
{
    uint value;
};

void main ()
{
    for ( uint i = 0u; i < 130700001u; ++i )
    {
        value = i;
    }
}

The shader compiles and links without errors. Shader is started with glDispatchCompute(1, 1, 1) and followed with glMemoryBarrier (GL_ALL_BARRIER_BITS) . SSBO creation, binding and readback is trivial and works fine for small loop counter value. But it crashes with huge repetiiton count. I’ve got an exeption not in glDispatchCompute but during next call for any OpenGL function. On my PC with 3060RTX the magic number is 130’700’001. With 130’700’000 repetitions all is OK.
As I can see from shader compilation binary output the shader code is same for all cases and looks like this

NVcp5.0
OPTION NV_internal;
OPTION NV_shader_storage_buffer;
OPTION NV_bindless_texture;
GROUP_SIZE 1;
STORAGE sbo_buf0[] = { program.storage[0] };
TEMP R0;
TEMP T;
MOV.U R0.x, {0, 0, 0, 0};
REP.S {130700001, 0, 0, 0};
STB.U32 R0, sbo_buf0[0];
ADD.U R0.x, R0, {1, 0, 0, 0};
ENDREP;
END

I have made a simple project to reproduce this behaviour - https://github.com/DrCorvax/SSBOfault

Please describe in more detail what you mean by “exception”. TDR? Display Manager crash? What do you see on the console you ran the app from? What do you see in the system event log?

You may already know about this, but on Windows, if a GPU shader “takes too long”, then Windows assumes the app has hung, kills the app, resets the GPU, and tries to resume normal, shared use of the GPU. This is a TDR. For more details, see:

If I ran program from Visual Studio IDE I’ve got a exeption message right after trying to execute glGetNamedBufferSubData:
Unhandled exception at 0x00007FF8C170FDE5 (nvoglv64.dll) in SSBOfault.exe: Fatal program exit requested.
And you are right - the problem is in TDR. Thanks a lot, I didn’t know about this feature. After increasing the timeout, the program was able to finish correctly.