Overlay died w/ except. => [class pmapi::ApiErrorException]

[NorthernLights]

System Specifications:
Microsoft Windows 11 Enterprise Insider Preview (Build 27686/24H2)
Intel Core i9-12900K
64GB DDR5-6000 RAM
nVidia Titan Xp (Driver v.560.70)
41TB of Available Disk Space

Version of Intel PresentMon: 2.1.1

Problem Description:
After installing Intel PresentMon, the GUI application opens and runs normally but when the game application is launched with any overlay, including custom, Intel PresentMon's overlay crashes repeatedly slowing down the game application until Intel PresentMon is stopped. The overlay never appears on the screen and when viewing the Intel PresentMon application, it is repeatedly showing that it is trying to attach itself to the running gaming application.

Notes:
Log files from Intel PresentMon and PresentMon service are attached. Log files obtained by following #223 (comment)

pm-srv-info-20240823-070351.20484.log
log.txt
cef-debug.log

[NorthernLights]

Update: After uninstalling MSI Afterburner and RTSS used for monitoring, a clearer log file has been generated by the PresentMon application and is reproduceable.

Error as seen in Logs:

[@Error] <renderer(67252):kernel(16460)> {2024-08-25 13:11:14.4581432 PDT}
  Overlay died w/ except. => [class pmapi::ApiErrorException] start process tracking call failed | Error: PM_STATUS_FAILURE (20) Failure: Operation failed
  >> at p2c::kern::Kernel::ThreadProcedure_ 
     C:\Files\Repos\drivers.gpu.tools.presentmon\IntelPresentMon\Core\source\kernel\Kernel.cpp(208)
[@Error] <renderer(67252):kernel(16460)> {2024-08-25 13:11:14.9444608 PDT}
  Overlay died w/ except. => [class pmapi::ApiErrorException] start process tracking call failed | Error: PM_STATUS_FAILURE (20) Failure: Operation failed
  >> at p2c::kern::Kernel::ThreadProcedure_ 
     C:\Files\Repos\drivers.gpu.tools.presentmon\IntelPresentMon\Core\source\kernel\Kernel.cpp(208)
[@Error] <renderer(67252):kernel(16460)> {2024-08-25 13:11:14.3559207 PDT}
  failed to begin tracking pid [70204]
  >> at pmon::mid::ConcreteMiddleware::StartStreaming 
     C:\Files\Repos\drivers.gpu.tools.presentmon\IntelPresentMon\PresentMonMiddleware\ConcreteMiddleware.cpp(225)
 ====== STACK TRACE (newest on top) ======
  [0] PresentMonAPI2!pmDiagnosticUnblockWaitingThread+0x33F6
  [1] PresentMonAPI2!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0x334BF
  [2] PresentMonAPI2!pmStartTrackingProcess+0x1C
  [3] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0x4D989
  [4] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0x54F1B
  [5] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0x50971
  [6] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0x4F39D
  [7] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0x37BB1
  [8] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::operator=+0x3A9A7
  [9] PresentMon!cereal::detail::StaticObject<cereal::detail::PolymorphicCasters>::create+0xEA2FE
  [10] KERNEL32!BaseThreadInitThunk+0x17
  [11] ntdll!RtlUserThreadStart+0x2C
 =========================================

Log Files (Updated)
log.txt
cef-debug.log

[planetchili]

Hello and thank you for your detailed report. Unfortunately we are in the process of adding more detailed logging to PresentMon and currently failures in the service and middleware leave few clues. From those logs it appears as though the error occurs in the middleware.

We are planning a 2.2 release by end of September, and there is a decent chance that your issue will be fixed due to some large changes made to the system as a whole. If this is not the case and you are still interested in pursuing this, we may be able to create a build for you with verbose logging in order to better narrow down the exact point of failure.

[NorthernLights]

I am indeed interested in helping to get to the bottom of this issue if the 2.2 release in September doesn't resolve the bug. I believe you are 100% correct that it is a middleware issue as I built from source using Visual Studio 2022 and Windows SDK version 10.0.26100.0 to target Windows 10.0.27686 (both were the latest at time of building) and was able to get a working, albeit somewhat buggy output debug solution.

Lines of code such as this appear in the log file (attached) of my build indicating middleware issues:

[@Error] <renderer(87608):kernel(76604)> {2024-08-29 01:31:58.4600294 PDT}
  [class pmon::util::pipe::PipeError] The pipe is being closed [system:232 at E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\CommonUtilities\vcpkg_installed\x64-windows-static\x64-windows-static\include\boost\asio\detail\win_iocp_handle_write_op.hpp:79:5 in function 'void __cdecl boost::asio::detail::win_iocp_handle_write_op<class boost::asio::const_buffers_1,class boost::asio::detail::write_op<class boost::asio::windows::basic_stream_handle<class boost::asio::any_io_executor>,class boost::asio::const_buffers_1,class boost::asio::const_buffer const *,class boost::asio::detail::transfer_all_t,class boost::asio::detail::write_dynbuf_v1_op<class boost::asio::windows::basic_stream_handle<class boost::asio::any_io_executor>,class boost::asio::basic_streambuf_ref<class std::allocator<char> >,class boost::asio::detail::transfer_all_t,class boost::asio::detail::as_tuple_handler<class boost::asio::detail::awaitable_handler<class boost::asio::any_io_executor,class std::tuple<class boost::system::error_code,unsigned __int64> > > > >,class boost::asio::any_io_executor>::do_complete(void *,class boost::asio::detail::win_iocp_operation *,const class boost::system::error_code &,unsigned __int64)']
  !PM_STATUS [0x00000014]:Failure => Operation failed
  >> at pmon::mid::ConcreteMiddleware::StopStreaming 
     E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\PresentMonMiddleware\ConcreteMiddleware.cpp(138)
 ====== STACK TRACE (newest on top) ======
  [0] PresentMonAPI2!`pmon::mid::ConcreteMiddleware::StopStreaming'::`1'::catch$14+0x295
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\PresentMonMiddleware\ConcreteMiddleware.cpp(138)
  [1] PresentMonAPI2!_CallSettingFrame_LookupContinuationIndex+0x20
    > D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm(98)
  [2] PresentMonAPI2!__FrameHandler4::CxxCallCatchBlock+0x1DE
    > D:\a\_work\1\s\src\vctools\crt\vcruntime\src\eh\frame.cpp(1439)
  [3] ntdll!RtlCaptureContext2+0x4A6
  [4] PresentMonAPI2!pmon::mid::ConcreteMiddleware::StopStreaming+0x99
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\PresentMonMiddleware\ConcreteMiddleware.cpp(129)
  [5] PresentMonAPI2!pmStopTrackingProcess+0x93
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\PresentMonAPI2\PresentMonAPI.cpp(226)
  [6] PresentMon!pmapi::ProcessTracker::Reset+0x4D
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\PresentMonAPIWrapper\ProcessTracker.cpp(38)
  [7] PresentMon!p2c::pmon::PresentMon::StopTracking+0x297
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\Core\source\pmon\PresentMon.cpp(83)
  [8] PresentMon!p2c::kern::Overlay::~Overlay+0x44
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\Core\source\kernel\Overlay.cpp(146)
  [9] PresentMon!p2c::kern::Overlay::`scalar deleting destructor'+0x23
  [10] PresentMon!std::default_delete<p2c::kern::Overlay>::operator()+0x4E
    > C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.41.34120\include\memory(3302)
  [11] PresentMon!std::unique_ptr<p2c::kern::Overlay,std::default_delete<p2c::kern::Overlay> >::~unique_ptr<p2c::kern::Overlay,std::default_delete<p2c::kern::Overlay> >+0x67
    > C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.41.34120\include\memory(3412)
  [12] PresentMon!p2c::kern::OverlayContainer::~OverlayContainer+0x87
    > E:\WinDev\PresentMonRepoDir\PresentMon\IntelPresentMon\Core\source\kernel\OverlayContainer.h(22)
  [13] PresentMon!p2c::kern::OverlayContainer::`scalar deleting destructor'+0x23
  [14] PresentMon!std::default_delete<p2c::kern::OverlayContainer>::operator()+0x4E
    > C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.41.34120\include\memory(3302)
  [15] PresentMon!std::unique_ptr<p2c::kern::OverlayContainer,std::default_delete<p2c::kern::OverlayContainer> >::reset+0x6C
    > C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.41.34120\include\memory(3447)
  [16] PresentMon!

Log Files (References)
cef-debug.log
log.txt

[planetchili]

Thank you for your continued support. Looking at the log from your build, it seems like your main issue indeed has been resolved incidentally. Some of the messiness you see in that log is likely due to running outside of the standard install location (perhaps you were running from the build directory or launching via IDE?) This can be fixed with a command line argument if you are interested (use --help to see the list of available parameters). Other errors in the log are due to some missing exception filtering/transformation that has since been added.

We were in the process of migrating to boost.Asio for the IPC mechanism between middleware and service, and there were some glitches that have since been ironed out. Hopefully this addresses all of your issues.

[NorthernLights]

I apologize for the delay @planetchili but I did want to revisit this as I may have inadvertently resolved the main issue by retargeting Visual Studio to use C++ Preview and the Windows 11 24H2 SDK as well as minor code adjustments but the latest builds just flat out fail using the latest changes to PresentMon on Git. I was running the working build from E:\WinDev (my directory for development on my RAID) but I didn't launch it from the IDE.

I've actually rewritten a lot of code to Boost.Asio as I saw it in there and will be working on the API and debugging the various parts to try and get a working build again but PresentMonAPI2 proves to be difficult. I will continue working side-by-side to see if we can resolve this issue. If I can get reliable working builds, I will be happy to submit all my changes for review assuming PresentMon is using C++ 20 or backported features to C++ 17. As I am on the bleeding edge, I have my target at C++ 20.

I accidentally deleted the log files but I was getting 0x14 error when PresentMon tried to access shared memory. I'm wondering if this has something to do with it. I will submit updated log files once I have working builds again to use.

[planetchili]

Thank you for checking in. Build errors are vexing to be sure. Collectively here we have built on 5 separate systems, Windows 10 and 11, VS 2022 and Preview, so your experience does not seem typical. Let me know if you're still having trouble getting the build working, share your build logs and perhaps I'll be able to provide some insight. We would of course like to provide a consistent and relatively frictionless build experience for anyone with the inclination to build PresentMon themselves.

We are setting most projects in PresentMon to C++20 or latest, so that shouldn't be an issue. Notable exceptions are PresentData and the standalone console app project, but it does not sound like you are making modifications in that area. I would certainly be interested in reviewing any proposed improvements to the Asio code you may have.

Errors with concerning the shared memory segments are concerning, so any logs you can share would be appreciated, especially if you have a consistent reproduction sequence.

[NorthernLights]

I was able to build successfully using VS 2022 and Preview both the current Git version and I resolved the issue with my modified version which had to do with how I was catching the logs. So as to not complicate things, I will address both builds in two sections due to the limited scope of comments.

The Current Git Version: Builds, Launches, but can't seem to access Shared Memory Space with error code 0x14. The only reason I know that 0x14 is a Shared Memory Space Access Issue is based off my Modified Build which implements a more detailed logging framework and when the Modified Build was throwing 0x14 it indicated it couldn't access Shared Memory. The logging for the Current Git Version is available below. Naturally, it still fails to load the overlay. This file is "log.txt"

The Modified Version which implements Boost.Asio heavily through the modification and completioin of certain areas of code doesn't appear to have that problem. Instead, most of its errors are thrown because it can't obtain PresentMon's clientPId so the service disconnects the pipes immediately after connecting. I haven't figured out what's wrong here but between the two builds, this is the most promising unless another bug crops up after determining why clientPId isn't being passed to ActionServer. Once this build is operating I'll be happy to submit any improvements for review but right now it is still in a state where it doesn't display the overlay and the service is disconnecting. The log file for this is 'log2.txt'

Log files below:

log2.txt
log.txt