Have you observed any notable details or patterns in terms of when those errors begin to show up for you?
e.g., Do those errors show up immediately after starting the app/in general, or is there some UI operations, panels, or features which reliably get those errors to show up?
If the repro happens early/quickly, ruling out GPU driver problems would be prudent, as we are not seeing or hearing feedback of that error in general. If it is a more specific use case, narrowing down that context would really help us to isolate for bugs.
Possible temporary workaround:
If you are comfortable with the "DVA Console" in Premiere, you can try set this debug flag to true. That will not fix the underlying issue, but will allow for restarting the app, using pre-existing GDI drawbot mode which should not hit that problem, until we can replicate the issue, and work out a proper solution.
Suppress D2D in Drover V7
Backing details: The "D2D Drawbot" mentioned in those errors is being used and tested together with the new "Spectrum" based Drover 7 skin and is part of the Premiere and AE Betas, at moment. D2D supports improved UI performance for a number of scenarios through the use of the GPU acceleration on Windows, and has been tested for integration across the breadth of the app, but you may have discovered some behavior which is incompatible or otherwise tripping on a bug or GPU driver.
For context, Premiere historically runs on windows with a "GDI Drawbot", which is software based, and has a number of known limitations. D2D Drawbot brings a performance and render quality benefits over the GDI based Drawbot, so I would not recommend the use of that workaround opt-out flag for anyone who doesn't really need it.
Due to how & when that error is detected, "call stack" information sadly doesn't provide useful context about the circumstances of this particular error, and these drawbot are used in innumerable scenarios, so any details you can provide which might help us narrow down the circumstance to replicate this issue would be very much appreciated.
Your suspicion of something around audio files on timeline or source monitor as connected to the repro seems possible as an area for a culprit. I know an engineer had fixed a bug in past of audio waveform rendering in timeline having size problems at high zoom levels. That one had entailed waveform draw performance issues when zoomed at high levels due to massive waveform previews. D2D based graphics cards and drivers happened to hit texture storage issues more quickly than the other drawbots, but all of them were succeptible to that bug. We may be looking for a similar but more nuanced issue here.
Follow-ups on Repro:
If you recognize sample files/project which seem to help you to reproduce with some consistency, that would definitely be of interest.
Any further observations of usage patterns like zooming changes or levels or other UI activity?
Can you elaborate on expectation vs reality for the irregularities with the audio transitions in timeline? Is that one directly connected to this or the D2D drawbot being turned off?
You mentioned of hitting the problem even with flag turned off. Two clarifying questions there:
Had you restarted the app after setting that flag - that flag can only take effect during app startup.
With D2D off, was the problem manifesting as the exception events or crash, or both? I would not expect that particular D2D exception to have been reachable if the flag was off, but similar malfunctions on other drawbots is more plausible.
We're continuing to monitor for this thread, if Ann or anyone else gets more information on the repro scenario which might help us narrow and replicate the errors.
For what's it worth, I have had the same error recently running beta version 24.6 Build 63. I have never actually seen this error until this update.
Across the board, Premiere has been impressively unstable in both the release and beta versions since 2nd or 3rd V24 update.
Hardware wise, I have a 13900k, 64gb of DDR5 RAM that is on my Mobo's QVL, and a Gigabyte 4090. I am running Studio driver 555.99 and on W10. I have no plugin's or strange custom settings either.
The only behavior I have noticed is that when this error occurs, RAM usage spikes drammically. Despite my settings, Premiere will use up to 59Gb of RAM and 99% CPU usage, while the UI locks and freezes. Sometimes, it will seemingly fix itself, but if I try to access any menus, the drop downs are blank.
Thus far, my only solution is setting Auto Save to 1 min and pressing a macro on my mouse to save as often as possible.
The hardware accelerated Direct 2D Drawbot used on windows may be hitting some unusual application behavior in your scenario. The failure of menus showing up means that OS window resources are likely exhausted.
This debug flag may help you mitigate the repro in short term(which goes back to a prior mode of UI rendering on Windows). If you find turning that on causes the issue to away, context on that would help confirm/narrow scope slightly.
Suppress D2D in Drover V7
Any insights on panels or notable UI associated with repro in the lead-up to this continues to be appreciated.
I have not found any clear steps to reproduce any of these errors. They seem to happen after editing for a bit (5-15 minutes) where I am just cutting up a timeline. The D2D error is new, but the freezing up with massive hardware usage is not.
I am going to update my Intel chipset drivers and GPU to the latest Studio drivers to see how that changes things. My Mobo does have a Bios update as well that changes the microcode, but I do not believe that is related. Might also update to the latest beta version of Premiere.
Thanks for the added context wrt the core issue possibly being independent of D2D use, and the occurrence around the audio cut edit, folks.
I'm reaching out with some specialists to see if they may have any data or supplemental ideas to help narrow this one further.
Given the nature of the error, and inability of OS menus to show - it sounds like Windows OS resources specifically had reached a limit, but aspects of the app not needing OS window resources were still operating without issue.
Based on recency of drivers, stale GPU driver is looking less likely as a key factor for this one.
The drawing error keeps happening, even after updating the Premiere Pro beta to the latest version. It seems to happen when Premiere freezes while I'm editing, and then it never recovers. The menus are blank, but the program registers when I click on things. I've had to memorize where the "save" button is located in the file dropdown menu because no other methods of saving work.
This is a major bug that is making it very difficult to use Premiere Pro. I have been editing video files of mixed formats, including MXF, H.264/5, MP3, and WAV audio. The bug happens with all of these formats.
We've isolated a repro for this error, and we're sorting out a mitigation.
When performing operations like enhancing sound, the Progress dashboard starts tracking progress of the audio operations. The button for progress view creates tooltips with current progress percentage. It looks like those UI tooltips were being generated very agressively in relation to progress, which was causing available Windows OS resource pool to get temporarily exhausted(which causes UI operations to start failing), as well as broader UI slugishness.
Until a fix is available for that, a workaround for above would be to avoid leaving the mouse hovering over the progress dashboard button while progress is occurring.
It is possible there are other scenarios for a generic error of this sort - Do let me know if the progress dashboard button when using audio operations does not seem related to the cases you have been hitting.
For the above scenario, switching off drawbot would indeed only change when symptoms of this problem were first detected, as the optional D2D drawbot was only the first component to detect the windows OS resource errors.
Im glad to hear yall have found a solution. Unfortantly, I have not noticed my error being connected to the progress dashboard as I never use that feature. I also have not noticed the D2D error since I first reported on it (not to say I still dont get a ton of crashes but that is a probably a different topic).
Did you say progress view was inactive with that MP3 scenario? And to confirm, that case was also hitting the D2D errors?
If more particulars for that repro emerge, I'll try to review with specialists around the audio scenarios to narrow down. On the active progress button scenario, a fix for tooltips was prepared earlier this week to start going into the beta builds.
With latest, are the freeze scenarios you mention involving Direct2D errors from the original postings?
To follow up, there was a fix for tooltips on the progress panel a couple of weeks back, which was affecting a bunch of audio processing scenarios, as well as a fix for errors with cases of UI resizing leading to errors reported with Direct2D Drawbot in particular which went into the beta builds starting Aug 14th.
If any folks still observe D2D drawbot errors like in Ann's original post in other situations, or with new builds that would be good context for any remaining cases of that.
Where you still encounter some problems independent of those D2D errors which seem to center on particular audio scenarios, I'd recommend a conversation to focus on that, so other affected users and specialists can more readily recognize context and weigh in on that part. Feel free to email me a link and I can mention it to some audio specialists to give a closer look at that part.
Don't know if this is relevant but when opening an audio file from the timeline with the cti over the clip, in the source monitor, the cti is always at the beginning of the source monitor. Never over the clip. One needs to double-click again on the clip in the timeline to get the correct cti position.
24
Replies
AdChoices