Environment
Revit 2025.4.5 (Build 20260410_1515, Branch RELEASE_2025.4.5)
Windows
pyRevit MCP (this repo), updated to latest version before final reproduction attempt
Both a Collaboration-for-Revit (C4R) cloud model and a blank local file were tested
Summary
Revit crashes reproducibly and unrecoverably shortly after interacting with pyRevit's ribbon (Settings, or general menu/tooltip hovering), whether or not Routes Server / the MCP bridge is actively being used. The crash happens on both a large C4R workshared model and a fresh blank local file, and persisted after updating pyRevit to the latest version.
Observed pattern (from two separate journal logs)
User interacts with the pyRevit ribbon (e.g. opens Settings, or hovers/clicks pyRevit tooltips like Wiki/Extensions/Update/About).
Revit logs an abnormally long Idling event callback:
The Idling event callback used 14 seconds (first crash)
The Idling event callback used 11 seconds (second crash)
An unhandled exception occurs immediately after, with the same exception address both times:
ExceptionCode=0xe0434352 ExceptionFlags=0x00000081 ExceptionAddress=00007FFF84751ADA
A Revit worker process is terminated (Revit worker 1 closed cleanly, then Terminating RevitWorker Processes), followed by an access violation (0xc0000005), and Revit crashes.
Notable details
The journals confirm PyRevitLoader registers an Idling event handler (API_SUCCESS { Registering Idling event by application PyRevitLoader ... }), which is the most likely source of the long-running callback.
Crash reproduced with RAM usage ranging from ~2.3 GB to ~34.9 GB in use — ruling out a memory-pressure cause.
Reproduced on both a cloud/C4R model and a blank local file — ruling out a model-specific cause.
Persisted after updating pyRevit to the latest release.
What would help
Confirmation of whether others have seen an unhandled exception originating from the Idling event handler in PyRevitLoader.
Any known incompatibility between this Idling event registration and Revit 2025.4.5 specifically.
journal.0122.txt
journal.0121.txt
Environment
Revit 2025.4.5 (Build 20260410_1515, Branch RELEASE_2025.4.5)
Windows
pyRevit MCP (this repo), updated to latest version before final reproduction attempt
Both a Collaboration-for-Revit (C4R) cloud model and a blank local file were tested
Summary
Revit crashes reproducibly and unrecoverably shortly after interacting with pyRevit's ribbon (Settings, or general menu/tooltip hovering), whether or not Routes Server / the MCP bridge is actively being used. The crash happens on both a large C4R workshared model and a fresh blank local file, and persisted after updating pyRevit to the latest version.
Observed pattern (from two separate journal logs)
User interacts with the pyRevit ribbon (e.g. opens Settings, or hovers/clicks pyRevit tooltips like Wiki/Extensions/Update/About).
Revit logs an abnormally long Idling event callback:
The Idling event callback used 14 seconds (first crash)
The Idling event callback used 11 seconds (second crash)
An unhandled exception occurs immediately after, with the same exception address both times:
ExceptionCode=0xe0434352 ExceptionFlags=0x00000081 ExceptionAddress=00007FFF84751ADA
A Revit worker process is terminated (Revit worker 1 closed cleanly, then Terminating RevitWorker Processes), followed by an access violation (0xc0000005), and Revit crashes.
Notable details
The journals confirm PyRevitLoader registers an Idling event handler (API_SUCCESS { Registering Idling event by application PyRevitLoader ... }), which is the most likely source of the long-running callback.
Crash reproduced with RAM usage ranging from ~2.3 GB to ~34.9 GB in use — ruling out a memory-pressure cause.
Reproduced on both a cloud/C4R model and a blank local file — ruling out a model-specific cause.
Persisted after updating pyRevit to the latest release.
What would help
Confirmation of whether others have seen an unhandled exception originating from the Idling event handler in PyRevitLoader.
Any known incompatibility between this Idling event registration and Revit 2025.4.5 specifically.
journal.0122.txt
journal.0121.txt