Tuesday, April 13, 2010

Revit '10 crashing & UIState.dat

A quick search on Google will reveal a number of posts about related directly to the UIState.dat file. Much has been made about deleting the UIState file in order to "reset" 2010's ribbon interface (Autodesk even publishes a tool and instructions). However, I've recently learned that corruption of this file is heavily suspected in cases of Revit 2010 crashing for no other obvious reasons.

As I've made mention before in different forums, generally my firm has held back from moving to 2010. However, its been un-avoidable for a number of reasons, on a number of projects. What has been alarming is the frequency of crashes we've seen/are seeing with users in 2010. Part of this may be in-sufficient hardware (as 2010 simply seems to be more intensive then 2009) or, another reason to blame may be more complex models. Several of our 2010 projects have structure and MEP (one of the reasons they are in '10 to begin with) which even on a small project greatly increases overall memory footprint when all files are loaded.

However, it turns out that the real cause of blame may be the UIState.dat file. I've been told (off the record) by reliable sources that if we have un-explained crashes (no warning, no recovery save, not in the middle of a significant operation) and in the journal file we see  just prior to the journal termination/exception error then there is a good chance that deleting the UIState.dat file will alleviate the crashing.

So far we've deleted the file on two PC's (mine being one) and with fingers crossed, we have not seen more crashes, but we need to give it some more time. I expect we'll be deleting the file from other's PC's in the near future.

The really wacky part was a case last week (while I was trying to enjoy Media Day). We had a user who, when he logged into one of our 64bit remote workstations, the moment Revit finished opening a file, and he did anything to affect the Ribbon, Revit crashed! It turned out that Revit was not creating any type of UIState.dat file for this user (though when I logged in, it created a UIState.dat file for me just fine). Furthermore the user could run Revit MEP without a problem.

Autodesk's only suggestion for this case was to delete the user's local profile from the machine, as there also seems to be cases where the whole local user profile becomes corrupted in some way.

Once the profile was deleted, the user logged back in, and Revit created a UIState.dat file without any problems, and so far has been stable.

Thus, all I can offer, is that if you have random crashes in Revit 2010, and they can not be reasonably attributed to anything else, and your journal file matches up with the above description, chances are you should start by deleting the Dat file, and if that does not clear the problem, delete the user's profile (by the way I take no responsibility for lost data if you do delete a profile, its up to you to know what you're doing, our IT staff already has it down to a science).

I'll also say, that off the record Autodesk is quite hopeful that this issue is resolved moving into 2011, however, even with Beta testing the numbers are simply not there to reveal a problem that is so hard to troubleshoot and hard to even be sure when it is happening. Indeed, to date I've not seen this problem myself in 2011, even though its occurred to me in 2010. We can but hope that this page has been turned.

2 comments:

Luke Johnson said...

Hi Robert, I have had the issue of crashing when tearing off the ribbon tabs - check it out at this link

Robert said...

In our case all users are running on Windows XP (32 or 64) SP2, we're not running any evaluation versions either. While in Luke's case there was some apparent connection to the Service Pack, it would have been interesting to see what happened if the UIState or User's profile were deleted.