Revit 2015 Revit.ini in ProgramData UserDataCache becoming 0-bytes

[r.robert.bell]

We are experiencing an odd issue the our Revit.ini files on several of our workstations. We deployed Revit 2015 with a custom Revit.ini file (we used the deployment tools to add the custom Revit.ini).

When we first install Revit, I have verified that the Revit.ini file located in %AllUsersProfile%\Autodesk\RVT 2015\UserDataCache has data, i.e. it is larger than 0 bytes. When the user launches Revit for the 1st time, they get the correct Revit.ini copied to the their %AppData%\Roaming\Autodesk\Revit\Autodesk Revit 2015 folder.

At some point after that, when they launch Revit, they get the warning about template locations being invalid. Examination of the Revit.ini files reveals that the user's Revit.ini file is mostly gone and, more importantly, the Revit.ini file in %AllUsersProfile%\Autodesk\RVT 2015\UserDataCache is now 0 bytes in size!

I'm at a loss to explain or recover from this issue. Reinstallation does not correct the issue. The only way to reliably recover is to uninstall Revit 2015, delete the user's AppData for Revit 2015 and reinstall.

Does anyone have an idea what's going on?

[Alaaeldin_Alsahli]

I think it is a security issue.

If you go to 

C:\ProgramData\Autodesk\RVT 2015\UserDataCache

and right click on Revit.ini and go to properties

Then Security TAB and for every user name and group give full permission without denying any permission and give it a try.

[Alaaeldin_Alsahli]

any updates if this solved it, to help other to find a solution if they have the same issue

[Lance.Coffey]

If the Revit.ini file was modified with a text editor other than Notepad, try opening it in Notepad, resave it, and then check if the issue occurs with the updated file.

[r.robert.bell]

Lance,

I initially used the deployment utility to add a custom INI to the deployment. The odd thing is that, as far as I can tell, the deployment is pushing out a correctly formatted Unicode INI file. But at some point Revit renames the INI file to Revit.ini.gen and then a blank Revit.ini file is created, which is not a correctly formatted Unicode file. Instead, the encoding is ANSI.

I'm attaching the deployment version of the Revit.ini file and the bad Revit.ini file. If you do a SaveAs with Notepad on either file you can note the encoding used by the file.

[r.robert.bell]

It cannot be a security issue. I've checked the effective rights for the users having issues for that file and they have full rights to the file.

[Alaaeldin_Alsahli]

The file you attached is not INI extension file, it is a TXT file. Please go to windows explorer folder option and uncheck hide extension and rename the Revit.ini.txt to Revit.ini

here is a video 

https://screencast.autodesk.com/main/details/43d4f0b2-e626-49f7-a7af-0b0f69cd66bf

Keep me posted

[rosskirby]

Hi Robert.

Sorry to be late chiming in on this, but we have had the exact same problem.  I was able to get around it by copy/pasting the correct ini file to "C:\ProgramData\Autodesk\RVT 2015\UserDataCache" and overwriting the Revit.ini file there.  Simple workaround, but a workaround nonetheless.

That being said, I have to agree that it is likely not a security/permissions issue, as that would affect every employee since we're all part of the same group policy.  I can't be 100% sure of this, but my theory is that the error is somehow related to the Autodesk Uninstall Utility, which is what our IT group uses when performing uninstalls of Autodesk software.  Here's how I came to that conclusion:

We had to uninstall and reinstall the BDSP 2015 suite on 5 machines in our office.  We were switching them from the networked licenses to standalone licenses (another story altogether).  Anyway, of the roughly 35 machines that had BDSP 2015 installed on them, 5 computers experienced the blank Revit.ini problem you describe.  Want to take a wild guess at which 5?

So, my question for you is: have you used the Autodesk Uninstall Utility on the machines with the error?  Or have you uninstalled/reinstalled at all?  If we could afford the downtime for anyone right now, I'd have our IT perform an uninstall/reinstall on a machine that has never experienced the error, but unfortunately that's a luxury I don't have.

[r.robert.bell]

Alaaeldin, you appear to be unaware that we cannot attach INI files to posts here. It is common practice to rename INI file or other text-based files with extensions that are not permitted with TXT extensions so that they can be posted and then renamed on your end after downloading them. I assure you the uploaded TXT file was the INI on our end.

[r.robert.bell]

Ross,

I don't believe, in the case of most of my users with this issue, that the 2015 version of the uninstaller was run. Most of these machines had no 2015 version of any Autodesk application prior to the installation of Revit 2015. The case is different for my own laptop... that did have the uninstaller run, probably several times. But I'm sure most of the other workstations did not have the 2015 uninstaller run.

[rosskirby]

Well, there goes that theory, I suppose.  Although there may be multiple ways to cause that 0-file size error in the .ini file.

You mentioned that it was only occurring on some of your workstations.  Do those workstations have anything else in common that is different from the uncorrupted workstations?  

Also, what kind of operating environment do you work in?  We have a "private cloud" of sorts, where all our machines are virtual, and our network pathing is name-based (i.e. \\arcturis\projects\etc.) rather than drive letter based (i.e. P:\\Projects\etc.).  Which of those two environments do you work in? Or do you have something completely different.

[r.robert.bell]

I have not been able to identify a commonality in the hardware itself. The OS and some applications (not Revit 2015) are installed by image so the underlying system should be pretty consistent.

We are installing physical hardware and this has happened on Dell Precision workkstations (T3600) and my Dell Precision laptop. I doubt that how we open projects, by mapped drive (primarily) or UNC (occasionaly), has any bearing since the INI gets messed up while Revit is opening.

Revit 2015 itself is installed separately by running a CMD so the actual installation of Revit is very consistent.

[Anonymous]

do you have the original .ini when u first setup your deployment image?

in the ini file, copy out :- example below
[Install]
InstallGUID={0900E16E-BFC6-4B26-9F7C-6C6C77EE98XX}

and replace back into the ini file found in the end user workstation in the user data cache.

remove the ini found in the user profile, believe it is under the roaming profile of the user.

you probably have modified your deployment image at some point of time.

Let me know if it works.

Rgds
Stephen

[r.robert.bell]

I have modified the deployment, several times since the initial deployment. Examination of a few of the original workstations shows that the InstallGUID is different than on other workstations that were deployed later.

Here is the interesting wrinkle though:

On two of the workstations exhibiting the issue I had unistalled Revit entirely and reinstalled yet the issue continued.

On another workstation that most recently had the issue, I installed only after modifying the deployment. So if modifying a deployment somehow causes existing workstations to have the issue, that could at least be trackable. But why would a brand new install of the modified deployment on a workstation that never had Revit 2015 cause this issue?

Is the deployment editing tool itself is only modifying the InstallGUID in Revit.ini and then not modifying that same value somewhere else in the deployment package? That's the only way that the issue occurring on a brand new install makes sense.

Also, with the brand new install, the user ran the application at least once without issue. So if modifying a deployement would somehow cause this issue, shouldn't it happen immediately? I suppose there is even something more mysterious happening. Does the order the secondary installer does things cause the first launch of application to work correctly and then it is only subsequent ones that break?

[Anonymous]

after you done an uninstallation - did you restart the computer.

some applications usually require a restart to clear out the remanent bits of code left behind.

if not got to the user profile - Appdata - roaming to delete away the Revit folder, and also in the Programdata\user data cache remove away the old revit.ini file. and .gen file

[r.robert.bell]

Yes, I rebooted after uninstalling. I also deleted the Revit 2015 folder in %AppData% and the Autodesk Revit 2015 key in HKCU before installing. The first time the user ran the application all was fine. At some later point (I don't know how many times the app was launched), the Revit.ini file in UserDataCache became 0-bytes and became an ANSI-based text file and not a Unicode-based text file.

The users are not manually doing this. Something from Revit is doing it.

[Alaaeldin_Alsahli]

I would try to modify the deployment again and put the original Revit.ini instead to norrow down and see if it is Revit.ini issue or something else within the deplyment that is the issue.

[Anonymous]

Revit.ini file in UserDataCache became 0-bytes, this happens when a repair was done to the installation from Program n features in the control panel at some point of time.

Do a clean uninstall, reboot, check that the programdata folders have been cleared out, and also under the user profile.

Reinstall again from your deployment image.


Rgds
Stephen

[r.robert.bell · Accepted solution]

Folks, I just figured out the cause because it finally (!) happened on my own laptop so I was able to significatly narrow down the variables.

The cause is Autodesk's own Revit Extensions (REX). At some point REX determines that it is missing a feature and kicks off a installer thread to add the missing feature (the GUID for the missing feature is {56B6EA8C-235B-4FCF-9BC8-54FC0720AFB8} but I don't know what the feature is because it does not exist in the registry).

It is at this point that the Revit.ini file gets overwritten.

My recommendation is to not install REX, at least until Autodesk corrects the installer. The reson for the recommendation to not install REX is because to correct the issue you need to unistall REX and Revit then reinstall Revit without installing REX. REX is also causing other issues that I'm not free to talk about and the recommendation from Autodesk for correcting the issue is the same.

I have posted more details on my blog.

[Alaaeldin_Alsahli]

I am Glad to hear that! Development team will try to reproduce issue and implement a Fix for Future releases.