The symptoms are easy to spot, the cause, not so much. The most visible symptom is that you launch Revit 2015 and Revit quickly displays a dialog box that the path you have specified for the default family template files is invalid. You ask yourself, "How? It was ok yesterday (or earlier the same day)." When you start looking at your file locations under Options you will note that your template locations are probably wiped out and Places has been reset to the out of the box (OOTB) defaults.
As you start poking around, trying to figure out what is going on, you will eventually discover that the Revit.ini file in the UserDataCache folder is 0-bytes in size (it is empty) and that the encoding is ANSI and not Unicode as Revit requires. You can determine the encoding of a text-based file in Notepad by starting a SaveAs and looking at the lower part of the Save As dialog box. For those of you that wonder where the UserDataCache folder is located, simply type the following into Windows Explorer's address bar:
%AllUsersProfile%\Autodesk\RVT 2015
While you now know what's wrong, you still have no idea why it happened. And that's where the research on the Internet gets frustrating.
Some claim it is due to a security rights issue. That can't be correct for several reasons:
- The file was good for days/weeks/months.
- The file was overwritten, so you had to have write rights for that to happen.
- If you check effective permissions on the file you will see that even normal users have full rights.
The next claim is that it is related to modifying a deployment. This seemed like the most like reason to me. After all, I wasn't seeing this issue on some of my early deployments but I was on more recent deployments. However, it was a red herring. The issue eventually occurred on my own laptop (thankfully! see below) and that laptop did not get deployed using normal deployments because I'm, well, special.
Another idea was that it was related to running Autodesk uninstalls on the workstation. This is not the case for most of my workstations experiencing the issue since they were new installs.
This left me scratching my head for over a month and a half. Until it finally happened on my own laptop. I was now able to remove the user from the equation. I knew that Revit 2015 was last ok a few days ago and this was the first time running Revit 2015 since it last worked. So I was able to dive into Windows Event Viewer and try to piece together what happened.
I had the timestamp of the bad Revit.ini file which gave me a target for looking in the event logs. And sure enough, there was something curious in the event logs at that time.
The Revit.ini file timestamp coincided with 4 events in the log. The entry I found really interesting was the one I have selected in the image below... Revit was reconfigured. Why was Revit reconfigured? And I remembered from that day that Revit had indeed displayed a dialog box in the afternoon that it was installing something. Of course, Revit didn't tell me what feature was getting installed. But the event log does!
Note the 4 log entries just before when Revit reconfigured itself. There are a couple of warnings there. I've selected one of the warnings. See what feature is having the issue? Autodesk's own Revit Extensions (REX)!
Subsequent examinations of my other workstations exhibiting this issue revealed that within the timeframe of a user reporting the Revit.ini issue that there was always corresponding warnings about REX in the event log. In all cases but my own laptop, there were multiple pairs of warnings and all those workstations have experienced multiple cases of the Revit.ini file being overwritten with a blank file with the wrong encoding.
Note that the missing component GUID in my screenshot, {56B6EA8C-235B-4FCF-9BC8-54FC0720AFB8}, cannot be located in my registry so I will continue to randomly experience this issue until I uninstall REX. The product GUID is Revit's own GUID and is ok.
My recommendation is to not deploy Autodesk's Revit Extensions until the issue is resolved by Autodesk. The reason for this recommendation is because if you have deployed Revit with REX deployed too, you will need to uninstall REX and then uninstall/reinstall Revit without REX in the deployment in order to correct the issue. It is best to not deploy REX unless you absolutely need it.
