I have the same problem in an interop (c#/c++ with D3D12) situation; and the POCO failure happened only when I use net7, not net4.8. I need to check with recent drivers update.
Exception thrown at 0x00007FFE11124B2C in D1_CustomContent.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000028AA3707F0.
Exception thrown at 0x00007FFE11124B2C in D1_CustomContent.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000028AA370830.
Exception thrown at 0x00007FFE11124B2C in D1_CustomContent.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000028AA37BD30.
Exception thrown at 0x00007FFE11124B2C in D1_CustomContent.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000028AA370720.
Exception thrown at 0x00007FFE11124B2C in D1_CustomContent.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000028AA370760.
Also seeing my app causing the screen to go black and the display being redetected after some resize events. But it’s inconsistent, so I’ll see the issue several times when debugging, then I won’t see it for 40 resize/move events.
I have a 3060, I’m using .Net 7 and Dx11 via Vortice Dx wrapper.
I wonder if this has to do with the color issue I was seeing. Which started happening after 531.18 I had to return my 3070 Ti because colors (maybe color space) would keep changing. I had a huge conversation with NVidia tech-support about it. The only driver that has worked all year is 528.49. I don’t remember seeing these exceptions before today though. But maybe I had exception messages disabled. Not sure.
scd.BufferCount = 1; // one back buffer
scd.BufferDesc.Format = DXGI_FORMAT_R8G8B8A8_UNORM; // use 32-bit color
scd.BufferDesc.Width = GetClientWidth(); // set the back buffer width
scd.BufferDesc.Height = GetClientHeight(); // set the back buffer height
scd.BufferUsage = DXGI_USAGE_RENDER_TARGET_OUTPUT; // how swap chain is to be used
scd.OutputWindow = _hWnd; // the window to be used
scd.SampleDesc.Count = 4; // how many multisamples
scd.Windowed = TRUE; // windowed/full-screen mode
scd.Flags = DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH; // allow full-screen switching
// create a device, device context and swap chain using the information in the scd struct
TOF(D3D11CreateDeviceAndSwapChain(NULL,
D3D_DRIVER_TYPE_HARDWARE,
NULL,
(IsDebugEnabled()) ? D3D11_CREATE_DEVICE_DEBUG : 0,
NULL,
NULL,
D3D11_SDK_VERSION,
&scd,
&swapchain,
&dev,
NULL,
&devcon));
0x00007FFF6CDD4FFC 处(位于 MT.exe 中)引发的异常: Microsoft C++ 异常: Poco::NotFoundException,位于内存位置 0x000000F563743120 处。
0x00007FFF6CDD4FFC 处(位于 MT.exe 中)引发的异常: Microsoft C++ 异常: Poco::NotFoundException,位于内存位置 0x000000F563743160 处。
My Computer Windows 11 x64, GPU RTX3080 Dirver Program 546.01 Visual 2022
Besides getting the aforementioned Poco::NotFoundException since ~2 years on my 2060 with latest drivers, I’m also seeing 8 Poco::FileAccessDeniedExceptions when attempting to manually Release an ID2D1Factory. You can replicate this issue by copying Microsoft’s D2D example at https://learn.microsoft.com/en-us/windows/win32/learnwin32/your-first-direct2d-program
Please fix, thank you.
I compiled the sample using MSVS 2019 16.11.32 on Windows 11 Pro 23H2 (OS build 22631.2861) and NVIDIA GeForce RTX 2080 SUPER with driver version 546.33.
When I run the sample, I get 3 Poco::NotFoundException messages but no Poco::FileAccessDeniedExceptions. Two of the Poco::NotFoundException messages occur in the call to CreateHwndRenderTarget (the function is declared in d2d1.h). The last Poco::NotFoundException message occurs in the sample SafeRelease call for the ID2D1Factory object.
The end of the call stack for these exceptions is in KernelBase.dll, which is called by NVIDIA’s MessageBus.dll. This is consistent with what others have reported in this forum thread. MarcusHoHo has already indicated the problem has been verified and will be fixed (but unknown in which driver release).
EDIT: I’ve just clean reinstalled my 546.33 drivers and no longer get the FileAccessDeniedExceptions aswell. The 3 NotFoundExceptions appear exactly as you mentioned now.
NVIDIA GeForce driver 546.65 release 17 January 2024 fixes the problem. The Poco::NotFoundException-s still appear in the Visual Studio output window, but the exceptions are not propagated to the application calling function (such as D3D11CreateDevice).
I get the exact same crash as @Gatchan reported with their stack trace, but then also got that Intel one from some user with Xe graphics. So, looking at that thread and how I caught crashes, it seemed that registering vectored exception handler and using it to catch exceptions early would actually catch HANDLED exceptions before they’d be able to reach the catch{} block in the original DLL, most likely.
It seems that NOT doing that vectored exception handling has that exception still occur but be non-fatal. So this is the open question to all the developers above, how were they catching these exceptions. If you had debugger attached, it’s actually very likely that if you pressed Continue, it’d actually keep running, it was most likely your debugger would catch it only as first-chance exception (before the app handles it).
On a side note, it’s a joke that Nvidia and Intel use exceptions in their drivers in the first place imo, a recipe for issues. It seems that only AMD doesn’t do that, at least not in a way that immediately causes issues like here.
EDIT: Contrary to what the poster above said, it was reported by user this still happens even on latest driver version as of creating this post (v555?)
I posted the original issue (March 7, 2023). In my code base, the POCO exceptions no longer occurred as of driver version 551.52 (February 13, 2024). I have installed currently version 555.85; the POCO exceptions do not occur.
As mentioned in my March 8, 2023 post, I use MSVS 2022 whose default for exception settings is <All C++ exceptions> disabled (box is not checked). The applications ignored the POCO exceptions. I then checked the box to enable all C++ exceptions, and the POCO exceptions occurred in the call to D3D11CreateDevice and on the final release of the device. Continuing to execute showed no problems. (My code has NO user-defined try-catch block surrounding the D3D11CreateDevice call.)
Regarding your side note, stating that exceptions in a graphics drivers is “a joke” indicates you might not appreciate the complexity of graphics drivers. They can contain millions of lines of code. Carefully used exceptions are helpful when testing and debugging the drivers. The issue in this thread is that the POCO (non-fatal) exceptions were passed along to the application code when they should have been caught in the driver and not passed to the caller.