@baldurk: It seems that I only get this problem if I do many calls to D3DX11CreateShaderResourceViewFromFile() to load a large image file (13,125 KB jpg)

I created a demo project which has the same problem.

Since the attached files are limited to 8.48MB, I uploaded the project here:

http://www.4shared.com/rar/GkQJa80Gce/Test_Crash.html

Thanks, I repro'd the crash. It's actually simply running out of memory - the program is creating a ~90MB texture every second or so. By default renderdoc saves a copy of this data on the CPU in case the texture is modified (so it can track changes in-place rather than needing to save every delta), eventually the allocation fails. I guess since it's a 32-bit process. I'm surprised how soon it fails actually as it only hits ~1.3GB for me, but maybe memory has fragmented enough that there isn't a large enough contiguous block. That's a complete guess.

I'll maybe see if I can add a heuristic so that large textures aren't shadowed unless absolutely necessary, but that still might not help depending on how many of the images are referenced in a frame. If they're all referenced, renderdoc will still allocate memory to readback their contents, and will be back to square one. I'd suggest either switching to 64-bit or using smaller textures if possible :).

@baldurk: Unfortunately, I have the same problem even if I reduce the image size to 2.5 MB in the project that I'm working on, although my entire project itself never exceed more than 250 MB of RAM during loading if I'm not using RenderDoc, it reaches 1.5 GB and then crash if I'm using RenderDoc.

@bioglaze: Thanks!

Do you have another repro project to share that still runs out of memory with smaller images? It's expected to see higher memory usage while using RenderDoc since it is storing shadow (CPU-side) copies of graphics resources. The memory for those graphics resources for the GPU is not counted in task manager, so it's 'invisible'.

Also just in case there is some confusion you mention that you reduce the image size to "2.5MB" which doesn't quite make sense. Even though your image is stored as a .jpg, the disk size makes no difference and compressing it further will not change the memory usage in D3D11. The memory usage is entirely determined by the resolution, format and number of mip levels - in this case the .jpg in the example project you uploaded is 5184x3456 and it is created as uncompressed R8G8B8A8 with a full set of mipmaps. That's where the memory use comes from not the file size on disk.

btw, this might be more appropriate to move to a github issue.