Thank you for reporting this - I assume you haven't isolated the particular operations which preceeded the crash? That 2005270494 error coming from Direct 2D/Windows OS normally suggests some operation may have leaked some windows OS Handle resources which were not getting properly reclaimed, causing the application to exceed OS allowed limits. Sounds like some kind of scenario involving color/lumetri in the lead up.
I'll take a look to see if I can narrow down the operations at play in that area- If by chance you observe a more specific pattern in terms of how you ran into the error, details would be welcome.
On possible mitigation - You *might* find the crash will not reproduce in the same manner if you optionally disable that Direct 2D based UI from General Preferences "GPU accelerated UI rendering (restart required)". In general, I'd recommend folks normally have that active, but it does suppress the Direct 2D Drawbot, which was complaining of conditions here. At the very least, the error would look different, if the legacy drawbot breaks on the same issue. If you try that and find the crash does or doesn't seem to reproduce, that would also be good context to help narrow down code which could be driving this issue.
Also - any brief insights you or others are able to capture about crashes like this in the crash reporter tool are incredibly helpful to aid devs recognize connected patterns with culprit on an issue like this, where a repro tends not to be straightforward.
I didn't have time for further work, that was right at the end of the day. And we're heading out for a long weekend this morning.
I was testing BRAW and mov (ProRes) footage from a BlackMagic Ursa Mini Pro 4.6k G2 (why they gave it such a long name is beyond me ...) in the 4.6k while trying out a mix of color management settings.
Including turning about everything off, some things on, and tracking what changes in the scopes. So I'd been working with the CM control options, especially sequence CM, like going to ACEScct to Red wide to ... whatever.
While changing the options in the next section below, on tonemapping and knee shape et al.
Then ... it lost image, and stopped functioning. I had to Task Manager quit Premiere. Relaunched, and within a couple seconds, got that message. Locking up Premiere and the computer, so Ctrl/Alt/Delete to force shut down options, to sign out of user to get operating again.
Brought up Windows, launched Premiere. Started playback, ok. Stopped, went to the Settings tab, touched something ... message again and locked Premiere. Had to Ctrl/Alt/Delete again to get out of Premiere.
I'll try digging into the paths you noted with some instrumentation and reach out with color team specialists to help get more eyes towards isolating the point of the resource leakage arising in this scenario.
If you or others have additional observations in relation to the circumstances of leading to this error, more data points are very much appreciated.
I'll be in-shop for awhile this afternoon, and that's the first thing I'll check. If there's a new beta build, I suppose I should just load that and see if I get the same behavior or not ...
Thanks for the update - I'm very glad to hear your new build seems to have stabilized for that. It's possible that your repro may have benefitted from a recent correction notably affecting source monitor on playback, or some other fixes.
From what I can tell, reasonably straightforward cases are addressed, but we are continuing to profile and search for potential sources of slow windows handle leaks which can still affect longer running Premiere sessions showing up with that same error.