Navisworks Install Problems

[raaber]

I have run into a problem with my Navisworks 2014 installation. I loaded it fine the first time but Navisworks would not display some of my walls. So I thought it might be a corrupt file so I re-installed again and got the following error messages

&

So I went to the Navisworks website and saw a comment to uninstall and remove the files in the Autodesk Programs folder and registry entries. I did that and tried to re-install but in the install wizard it tells me these files have been already installed

Now I can't get the setup program to see there is no programs installed and allow me to proceed with my re-install. Does anyone have any ideas?

[AndyG_ADSK]

Hi there,

What was the website you went to that recommended deleting files and registry entries?  Was it an Autodesk-owned page?

Just for anyone else reading this, attempting to delete files and registry entries yourself is about the worst thing you could do.

More helpfully, the best way to proceed from here is to try to get back to a functioning installation, so you can uninstall and re-install in a more orderly fashion if still required.

As you have Manage 2014 installed you will need to repair your install with the following commands:

On a 32 bit platform, run these commands:

msiexec /fvomus {E8D5A6C0-5E25-0000-88AB-12C63BCBEBA2}
msiexec /fvomus {E8D5A6C0-5E25-0409-88AB-12C63BCBEBA2}

On a 64 bit platform, run:
msiexec /fvomus {22332F6C-46C6-0000-9863-06EE744B0218}

msiexec /fvomus {22332F6C-46C6-0409-9863-06EE744B0218}

If you have the same problem with Freedom and the Exporter plug-ins tell me and I will give you commands for those.

Cheers

Andy

[Krytus]

@AndyG_ADSK, Your attempt to help with the apparently common failed install/reinstall/blocked-uninstall plague is greatly appreciated, and even helped me get half a step closer to a fix, but I discovered something odd that other users would benefit from knowing.

Although this topic is for an issue from many years ago, the problem still occurs in other versions and other software from Autodesk, and I may have found the cause and solution for a potentially overlooked detail.

I too had the unusual problem with Navisworks Manage 2014, but in both directions, in my case. After 2 pain-staking days of trial and error, and exhaustive testing on 4 different systems (3 virtual+ 1 physical, all Win7) with different generations of updates, I hit a breakthrough when one line in the software list for the oldest system didn't add up...

And the solution?   DESTROY C++!

Any version of Microsoft Visual C++ Redistributable after 2013 may cause the install AND removal of some Autodesk software to hang and become unresponsive. To test this, completely erase ALL installed versions of MS Visual C++ on an affected system, and the install/removal process should proceed normally.  *But there's no guarantee that will work in all cases, depending on how the OS is configured.

[AndyG_ADSK]

@Krytus Well done for working that out!

I would say that if you have versions of the Microsoft Visual C++ Redistributable installed then it's highly likely that other applications need it to be installed, so if this solves the problem then great, but please take care to re-install the appropriate versions of Microsoft Visual C++ Redistributable afterwards.

[Krytus]

@AndyG_ADSK 

On the one hand yes, VC++ is important, but on the other, it's pretty easy to accidentally have too many versions installed.

Also, I'm now having a different variety of the problem on this topic, on another system. After applying my own suggested VC++ removal fix, any install/uninstall of Navisworks from 3 different fresh installers (IDSU, FDSU, and vanilla Navisworks) which I kept for comparative and diagnostic reasons, hangs at the "determining installation requirements" stage and never proceeds to the functional portion. However, my VC++ fix did allow me to work with it as an msi packet through the use of the commands you suggested, and I can even prepare the SP2 update... but now there's a weirder problem; the process window gets all the way to about 90%, like it was before my proposed fix, but now, I can trick the process to moving on by threatening the OS with a soft-reboot by hitting Restart from the windows start menu-- then an overlay shows an error describing the msiexec-based operation being too busy to allow shutdown-- and then cancelling the reboot with the button on the lower right area of the warning overlay... and I have to do this at least 3 times (as many times as the process stops moving and hangs idle) to get it to finish. It's incredibly pain-staking and difficult, but it can work for limited uses like in-place repairs and pushing an update if the user is extremely desperate (or in my case relentless trial and error with mixed results).

What that means is that in some cases, I still can't do a proper uninstall/reinstall, and in other cases I can't even do a fresh install! So my VC++ fix works for maintaining an assembled system, but now I need your help for a comprehensive fix. I've already looked everywhere, checked your other posts, tried your msiexec commands, and a number of cleanup strategies to freshen the base OS, but to no avail. If at all possible, I would like to send a copy of my worst-affected virtual machine (as a reference for the problem which also affects physical systems) to you personally for a comparative diagnostic.

~~And one more note: I observed that installs work perfectly on W7 systems that have never touched ESU updates (but it seems early ones from Feb 2020 are fine) though on a system that has had many ESU updates, even after carefully removing all of them and scrubbing the system, any attempt to install/uninstall Autodesk software of any kind from the 2014 and 2015 versions (what I've tested so far) does nothing but hang and idle endlessly. I would really appreciate professional insight on what, if anything, can be done about this without reinstalling the OS.

[AndyG_ADSK]

Krytus,

Wow! Random thoughts that might be useful:
If you're getting to 90% through, it's likely the actual installation is taking place at that point -- MSI installs spend a long time checking that an install is likely to succeed before doing anything. A hang might be "prompting for source media" or some other problem accessing files that it would like to copy to your computer. You should be able to look in the %temp% directory for logs which should semi-cryptically indicate what's going on. Things like repairs will want to access to the original source media location to restore the original files. I'm guessing threatening a reboot is killing the hung process so you're in effect treating the symptoms rather than the cause. Looking at the logs should help determine the issue.

In terms of fresh installs, Microsoft have released some installers that depend on certain windows updates, which I think is a wrong turn really but they forgot to check with me first. For example, the VC++ Redists depend on the C Runtimes which are installed through Windows Update. Another wrong turn is that the C Runtimes have a dependency on lots of other windows updates, not a genuine dependency, more of a bogus "we would really like you to have various security updates installed" dependency. These security updates will have dependencies on other things, and so on and so on. The upshot is that an install on a machine that isn't up-to-date with windows updates can take a very long time. Longer than I ever had patience for. I wrote a little wrapper around the C Runtime installer to install it directly without going through the windows update system to avoid this problem. That was included in Navisworks and many other Autodesk installers 2017-2021 as 3rdParty\ucrt\AdUcrtInstaller.exe. You could try running that before your installer as a way of trying to stop the installation heading off over the horizon in search of windows updates, but the best fix would be to install all the recommended updates until windows update is happy with your system.

As regards sending me VMs or logs, you can send me private messages here and we can work out the best way to do it.

Kind regards,
Andy

[Krytus]

Actually, it's not installing anything until after 90%. I know because, in numerous tests, the update(s) wouldn't install, nor would your msiexec commands proceed, until after the 90% point. Proof is that in every instance of installing an update, it would prompt me to direct the process to the original NAVMAN install media as a reference, but NOTHING BEFORE that point. So I had to trick the system because of the hang!  The logs don't tell me anything meaningful, it's all just repetitive junk that points a finger at msiexec.exe crashing (even after I remove updates to downrev it).

There are no hung processes as far as I can tell, and I speculate that something is going on because of recent Windows ESU updates, and I replicated the entire problem on a very empty Win7 VM I use for reference deployments, which is loaded with ESU updates, stripped it bare down to mainstream updates, and still get the hang problem.

And actually, ADSK installs on less-than up-to-date W7 systems is neither slow nor problematic, as long as it's not lagging too far behind 2017 (when the code structure for some updates started to change).

In terms of that last part, "but the best fix would be to install all the recommended updates until windows update is happy with your system." That's fundamentally what I did years ago by making a clean reference VM for quick maintenance with all updates until the end of mainstream/extended support (Jan. 2020) and everything from Autodesk works harmoniously on that reference VM-- but stalls out entirely on the variation I made with ESU updates applied.

So I'll pack the affected reference VM (which really can be used as a reference since this issue will likely affect other users with similar technical habits like using Autodesk programs and installing ESU updates) and find a way to send it up, being sure to put notes in the VM's description area.

[AndyG_ADSK]

I think we are agreeing on the behaviour of MSI installers.  I can look at the logs if you like.

[Krytus]

Well, I sent you a PM with details and a copy of a VM with the problematic behavior, so I imagine you'll figure it out once you download it and look at how it works. Also, this is going to be a lot deeper than just looking at logs.