Adobe Premiere Pro 2026 — Intermittent Hang on File/Folder Dialogs

Summary

Premiere Pro (26.0.1.3, Windows 11 24H2, build 10.0.26100.8655) intermittently freezes completely ("Not Responding") when opening any Open/Save/Browse dialog — including Save As, Import, and the Scratch Disks "Browse" folder picker. The freeze is a genuine hard hang (Windows logs it as an Application Hang, "Top level window is idle"), not a cosmetic or offscreen-window issue. Two independent crash dumps show the identical stuck call stack.

Environment

• Premiere Pro version: 26.0.1.3 (Premiere Pro 2026)
• OS: Windows 11, version 24H2, build 10.0.26100.8655
• RAM: 64 GB
• GPU driver: NVIDIA (nvwgf2umx/nvcuda64 present in dumps)

Symptom

• Premiere becomes fully unresponsive. Clicking anywhere produces the Windows system "ding" (rejected input on a blocked modal).
• Occurs after a variable amount of session activity — anywhere from ~30 minutes to ~3 hours. Not tied to a fixed elapsed time.
• Only ever triggered by opening a common file/folder dialog:
  • File > Save As
  • File > Import
  • Project Settings > Scratch Disks > Browse
• Never triggered by scrubbing the timeline or any other UI activity in isolation — those actions were specifically tested and do not cause the hang on their own.
• Restarting Premiere always temporarily resolves it (until the pattern recurs).

Root cause (from crash dump analysis)

Two full memory dumps were captured (via Task Manager → Create Dump File) at the moment of hang, on different dates, triggered by different dialogs (Save As on one occasion, Scratch Disks Browse on another). Both show the main UI thread (thread 0) stuck in the identical call stack:

Adobe Premiere Pro.exe
 Frontend!FE::Run
 ...
 Dialogs!DLG::AskSaveFile  /  Dialogs!DLG::ScratchDisksProjectControlGroup::OnBrowse
 dvaui!dvaui::dialogs::OS_FileSaveAsDialog::RunModal  /  OS_FolderChooserDialog::RunModal
 comdlg32!CFileOpenSave::Show
 comdlg32!CFileOpenSave::_InitOpenSaveDialog
 comdlg32!CFileOpenSave::_JumpToInitialLocation
 shell32!CExplorerBrowser::BrowseObject
 shell32!CExplorerBrowser::_BrowseObjectInternal
 shell32!CExplorerBrowser::_BrowseToView
 shell32!CExplorerBrowser::_SwitchView
 shell32!CExplorerBrowser::_CreateViewWindow
 shell32!CDefView::CreateViewWindow3
 shell32!CDefView::_CreateInitialCollection
 shell32!CDefView::_CreateNewCollection
 shell32!CDefView::_SetItemCollection
 shell32!SHProcessMessagesUntilEvent   <-- blocked here, waiting indefinitely

The main thread is blocked inside the Windows shell's embedded Explorer-view control (CDefView/CExplorerBrowser), waiting via SHProcessMessagesUntilEvent for an event that never arrives. This is standard Microsoft-provided shell UI that Premiere hosts in-process to implement its Open/Save/Browse dialogs. No exception, no deadlock warning — the thread is simply parked waiting on a signal that is never sent.

Investigation and ruled-out causes

The following were investigated and ruled out as the cause:

• OneDrive / cloud storage: Hang reproduces on local-disk-only operations (e.g., Scratch Disks browse pointing at a local drive), so it is not specific to cloud-synced folders.
• Windows Quick Access / recent-files cache: Cleared and disabled auto-population; hang still occurred.
• Third-party shell extensions:  MacDrive 10, which hooks Drive-level context menus and was a strong initial suspect given frequent use of Mac-formatted external drives) were disabled via ShellExView. Hang still occurred afterward with the identical stack.
• Disconnected/stale network drives: No mapped network drives exist on this machine (net use returns empty); no greyed-out or phantom drives in Disk Management or Explorer.
• Stale "jump to last location" MRU pointing at an unplugged USB drive: Ruled out — a hang occurred in a session where no external drives were connected or disconnected at any point.

GDI object correlation

Using Task Manager's Handles/GDI/USER object counters and a custom monitoring script sampling every 30 seconds:

• GDI object count for Premiere Pro.exe climbs steadily during normal use and never drops back to baseline.
• General UI activity leaks GDI objects broadly — not just dialogs. Isolated testing showed:
  • Opening and immediately cancelling a Browse/Import/Export dialog (no navigation) leaks ~3–6 GDI objects per cycle, consistently, every time.
  • Scrubbing the timeline leaks GDI objects at a noticeably higher rate per action (one scrub session moved GDI from 208 → 224, a jump of 16) — despite scrubbing never once causing a hang on its own.
• GDI count at time of hang was not consistent across occurrences (~455 in one case, ~300 in another) — both far below the ~9,000–10,000 per-process GDI object ceiling Windows enforces.  GDI level appears to be a rough proxy for "how much UI activity this session has done," not a causal threshold.
• Despite deliberately repeating the exact dialog-opening actions many additional times in a focused test session (well beyond what preceded either real hang), the hang did not reproduce on demand — consistent with a timing-dependent race condition rather than a deterministic trigger.

Conclusion

This appears to be an intermittent race condition in Premiere Pro's hosting of the Windows common file/folder dialog (comdlg32/shell32 CDefView/CExplorerBrowser), where the main UI thread can become permanently blocked in SHProcessMessagesUntilEvent while the embedded shell view is being constructed. It is reproducible only via genuine, extended editing sessions and has not been forced via isolated stress-testing of any single action, suggesting the trigger depends on the state/timing of other concurrent background activity within Premiere at the moment a dialog is opened.