Crashes suck

image by archi-lab

I won’t belabor the point. But to scrape the surface of what merits a full-blown rant, they kill time twice: You lose the time it takes for Revit to reopen and the hours since the user’s last save.

Avoiding crashes has obvious upside, so that’s the goal. But there’s no silver bullet. A strict regimen of regular model maintenance, following best practices, and staying on top of hardware usage and software updates is a good place to start. Yet, crashes still happen. They’re an inescapable fact of Revit.

But if you can’t beat them, measure them.

Then beat them.

By looking at the data, we can monitor crashes globally, spotting spikes and outliers. Armed with our dashboards and a histogram of Revit events and journal logs, we can work toward targeted solutions to reduce crash events.

How to Track Crashes

Revit can crash for countless reasons and in a couple of ways. Sometimes Revit keels over and doesn’t tell us that something happened. Other times, crashes are preceded by a pop-up with words such as “a fatal error has occurred” or “Revit has experienced an unrecoverable error and must close.” These errors indicate critical failures that force Revit to shut down.

A quick detour before we continue: not every Revit error brings the program down, but many signal lurking issues that can tank productivity and eventually trigger a crash. For example, we can flag memory-related warnings by filtering for dialog IDs like TaskDialog_Virtual_Memory_High_Usage, TaskDialog_Not_Enough_Memory_To_Save, or messages containing “out of memory.” Those errors tell you exactly which machines need a RAM upgrade. For the rest of this post, though, we’ll focus on the more ambiguous, fatal crashes and how Bimbeats data helps you chase them down.

With Bimbeats, we can flag these crash events by filtering for logs where the message field contains words like “fatal” or “unrecoverable.” Next, we can map those events along a timeline and group them by user and model to get a map of crash events over time. 

Spikes jump off the screen, showing examples when and where the crashes happened. You can even rank the users and files with the most crashes in any period.

How to analyze them

We now know the who, what, when, and where. Let’s chase the why. We can use the data collected by Bimbeats to find clues as to what might have caused a crash..

Equipped with the knowledge of which user or Revit model experienced a peak in crash events, along with the time of the crash, we can look into suspected markers for crash frequency, such as model health of hardware utilization. 

Starting with model health, you can look into the Model Traffic Light Metrics Dashboard, which surfaces classic red flags such as large file size or excessive warnings. Anything of concern lights up red. 

In this particular case, we cannot see any outliers that would cause this model to crash with such frequency. 


Next, we can look at PC performance. A crash could be caused by a lack of available drive space, long PC uptime, or excessive RAM utilization. Here, though, everything looks healthy for the day of the peak in crashes.

We’re still short on clues, but we can look even deeper by seeing the timestamps of these crashes for that day and user. By heading over to the Discover window of Kibana, we can filter documents to only show us crash-related logs from that particular user, on the day in question.

We can then look for those timestamps in that user’s “revit-journal” to see what actions were taken leading up to the error

Time and time again, the Revit journal log shows us that the user had a video driver error when trying to print multiple views. 

We now have the information we need to take action. In this case, IT rolled out a driver update that significantly reduced the number of crashes for this user. That’s one story, and one of many ways you can use Bimbeats to track the causes of a problem.

Conclusion

Crash forensics isn’t magic, it’s detective work. Bimbeats gathers the data in one place so you can zero in on the usual suspects: model health, hardware, or user behaviour, and help you find the root cause of crashes faster, thereby reducing their impact on your team’s productivity.

Using Bimbeats, you can turn crashes into actionable insights.

The plug

Now is the time for a shameless plug.

This analysis and many more are possible with a tool like Bimbeats. Go check it out at Bimbeats.com. If you like it, reach out to me, and I will be happy to schedule a demo with you. Here’s my calendar.

Leave a Comment