POCO::NotFoundException thrown in driver version 531.18

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.

It’s not a c#/dotnet or c++ problem.

The call stack finishes like that:

KernelBase.dll!RaiseException() Unknown
MessageBus.dll!00007fffa447cb4d()   Unknown
MessageBus.dll!00007fffa427af4e()   Unknown
MessageBus.dll!00007fffa41fe097()   Unknown
MessageBus.dll!00007fffa4210919()   Unknown
MessageBus.dll!00007fffa420ac95()   Unknown
MessageBus.dll!00007fffa42085d0()   Unknown
MessageBus.dll!00007fffa420fe91()   Unknown
nvwgf2umx.dll!00007fff876e8da7()    Unknown
nvwgf2umx.dll!00007fff876ea202()    Unknown
nvwgf2umx.dll!00007fff876d9e64()    Unknown
nvwgf2umx.dll!00007fff878dc16b()    Unknown
nvwgf2umx.dll!00007fff87bb8a70()    Unknown
nvwgf2umx.dll!00007fff88c9725b()    Unknown
D3D12Core.dll!NDXGI::CUMDAdapter::OpenAdapter<0>(void)  Unknown

I’m seeing this in 536.67.

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.

Yes please fix this, I am getting this exception on startup of a game I’m working on(written in C++).

It started a week or two ago with a driver update(Driver version 531.79)

Exception thrown at 0x00007FFA43E4CF19 in Cloud.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000071A5AF02E0.

If I step passed the first exception I get the same exception at a slightly different memory address.

Exception thrown at 0x00007FFA43E4CF19 in Cloud.exe: Microsoft C++ exception: Poco::NotFoundException at memory location 0x00000071A5AF0320.

It happens when calling NvAPI_D3D11_CreateDeviceAndSwapChain

	 if (result != S_OK  &&
		 CanUseDriverExt &&
		 NvAPI_Initialize() == NVAPI_OK) {//Now try Nvidia

		 result = NvAPI_D3D11_CreateDeviceAndSwapChain(adapter, static_cast<D3D_DRIVER_TYPE>(driverType), nullptr, static_cast<UINT>(deviceFlags),
			 FirstFeature(), u32(gFeatureLvls.size()), D3D11_SDK_VERSION,
			 &swap_chain.GetSwapChainDesc(), com::recv_ptr(swap_chain.Swap_Chain()),
			 com::recv_ptr(_Device), (D3D_FEATURE_LEVEL*)&featureLvl, com::recv_ptr(imContext.raw_context()),&nvidiaFeatureLevel);

For now I will just force the debugger to ignore this exception, but you should really fix this.

Driver: 537.42
Card: RTX 4060 Ti
Windows: 10 x64

Error is still present.
How many years before this gets resolved?

Same here…

Driver: 537.13
GPU: GTX 1070
OS: Windows 11
Visual Studio 2022 17.5.3

I am now seeing this error too:

Studio Driver: 537.42
GPU: GTX 3060 & Quadro T1000
OS: Windows 10
Visual Studio 2022 17.7.4

I have also run this scenario on a different PC using older drivers 536.96 and everything works as expected.

I just got the error in a call to CreateDevice on Direct3D 11.

Driver: 546.01
GPU: RTX 3090
OS: Windows 10
Visual 2022 17.7.5

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
	(IsDebugEnabled()) ? D3D11_CREATE_DEVICE_DEBUG : 0,

Welcome back to the NVIDIA developer forums @j2inet and thanks for confirming this issue.

I do now have information that this issue was addressed, but I don’t know yet when exactly it will be part of an official driver release.



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).

1 Like

Thanks for checking!

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.

I get 2 Poco::NotFoundException on driver 546.33 on a RTX 3090 when calling

EGLBoolean success = eglInitialize(display, 0, 0);

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).

Please thank the driver team for fixing this!

NOT fixed for me with GeForce Game Ready Driver 546.65 release date 01/17/2024

I’m still seeing the “Microsoft C++ exception: Poco::NotFoundException”

It’s occurring when I execute vkQueuePresentKHR, I receive a “Microsoft C++ SEH Exception” Vectored exception: 0xE06D7363

Apparently I incorrectly tested using 546.65. Running my samples today, I still get the exceptions propagated to D3D11CreateDevice. My mistake.

✅ Issue resolved!
Driver: 552.22
Card: RTX 4060 TI
Windows: 11

This actually seems like might be similar case to: Re: ShaderCache::ShaderCacheFileBackedEmptyCacheFileException after driver update - Intel Community

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.