Revit crashing when adding Package Path in Dynamo 2.0.1


I have just started testing Dynamo 2.0.1, and both Revit 2017.2 and 2018.3 crash when I try to add a path to the packages, saved in a network location.
I get the Revit error report and the message ‘A fatal error has occurred. The application will be terminated, etc’.

Note - I also have Dynamo 0.9.1 and 1.3.2 installed on the machine, and Revit 2016 to 2018.

Has anyone else been experiencing the same?



Don’t add all your packages to dynamo at once, theres probably some incompatible ones.

1 Like

Spot on, thanks @Michael_Kirschner2!
It was the #bakery and #archi-lab _Mandrill packages. everything works when installing everything except those 2 packages.
Thank you

1 Like

I am not sure the issue would be with Archi-lab_Mandrill as I am able to use it just fine with 2.0:

Also works fine too:

Working package versions:


I got the same issues:

  1. Clockwork fro dynamo 1.x and
  2. Lunchbox for dyanmo did not worked and made it crash.

I have a lot of trouble to get the ArchiLab going @Konrad_K_Sobon even after flushing all dynamo data and re-install. Another topic/// Archi-Lab and Dynamo 2.0.1

but you did get it to work which tells me that the real issue here is:

  • package manager
  • dynamo installer

The issue with Package Manager has been well documented over at the Git Hub’s issues page but the Dynamo team doesn’t seem to give a damn. I am sorry @Zach_Kron but there is no way around this. The package manager has been a pain in the arse ever since its inception and no changes were ever made to it. There was a lot of talk, interviews, consulting companies, countless github issues and no action whatsoever. I know it was placed on someone else’s TODO list, but that’s hardly a solution. Anyways…

…and there is the Dynamo installer, that ships with Revit, and does all sorts of weird stuff. I really don’t know what to tell people when they say: Oh I uninstalled Dynamo, and then tried again. Well as it happens I doubt that the uninstaller actually removes any of the relevant parts from the user computer. I know it leaves %appdata% stuff in place, and most likely some other files which basically means that users need to know that even after they uninstalled Dynamo, they still need to check some 3-4 odd locations on their drives to REALLY get rid of it. Of course that’s on someone else’s list of TODO tasks too…

This is infuriating because the blame gets shifted to package owners, that makes them look like bunch of slobs that can’t get a package together and cause crashes on user computers.




I second what you are writing @Konrad_K_Sobon. That makes the dynamo tools unreliable in many ways.

I know it is free, but that does not mean the tool is not used for production in great extents and we rely on it to leverage culprits and impossible things with Revit.

Amour / Haine
I love Dynamo for what it allows and teached me everyday, I hate it for its unreliability.

@Zach_Kron, What do we do about it?

:point_up: this. a million times this.


@Konrad_K_Sobon @john_pierson did not mean to imply that your packages cause crashes generally, just that maybe @Jean-Marc or @monica.greco was trying to load an older version which is no longer compatible with 2.0

but I understand what you mean.
I would hardly be able to exactly reproduce the case though, that involved too many steps

I have an issue with the statement that “Dynamo is free”, so we can cut the developers some slack. It’s Open Source for the most part, and it’s free for the most part…but not really.

If you were to download the “free” Open Source Dynamo and run it on your machine then it’s pretty bare bones. It doesn’t have a geometry library (only the Dynamo Studio ships with it, while Dynamo Revit relies on Revit libraries). So basically the Sandbox version of Dynamo that is free, comes pretty handicapped, and for sure not really useful for AEC industry.

Now, majority of people here, actually use Dynamo Revit, which comes installed with Revit. That means that it’s not really free, because Revit is not free and since we already established they are not very useful when mutually exclusive, then I would say that Dynamo is not free. Also, now that the Revit team is taking over development of the Dynamo Revit library, as well as the fact that Revit folks have been claiming Dynamo Revit to be an extension for Revit, then I would really be hard pressed to consider Dynamo Revit a free tool. It’s Open Source but not free, since I can’t do anything with it on its own.

That’s just my 2 cents.


Hi guys, I didn’t mean to start such a conversation.
@Konrad_K_Sobon - I can just imagine the amount of effort you put in your work and can’t thank you enough for how quick you always are to help and answer questions.
I was more thinking the reason why my Revit is crashing is because I have too many versions on Dynamo installed, plus the packages need to be in a network location. Unfortunately we are still using Revit 2016, and working with so many different Revit/Dynamo versions is not always easy to manage.
Will give it a go with installing the packages on the local drive, see if that makes a difference.
Thank you

PS I was installing the latest versions for all packages

Update - No crashes when installing to the local drive.
Plus, today it’s crashing again when trying to load the path to the folder on the network, even without those 2 packages installed.
Looks like the problem is having the packages on the network drive. Nothing specific to any package.

@monica.greco you did nothing wrong. These conversations need to happen for the Dynamo team to be aware of the issues that we are facing with their product. It’s a good thing.


The network path thing is very promising, but I rarely see it function as needed. This actually derailed our entire lab at AU2017. The FRA.ME computers did not like remapping.

The best solution I have seen is a script that runs on user login. The script copies files locally into APPDATA, and it just works.


@Konrad_K_Sobon I can imagine a dynamo or a logical graph with what you are saying. :wink:
You’re so right.

@monica.greco the network drive does not work properly indeed. the storage of the pachages path in dynamo does not seem to work as expected: add network path, delete appdata path, restart dynamo, the appdata is back again (and you eventually crash)

what @john_pierson is proposing works just fine.


We have empty Appdata/dynamo/packages folders on all computers, and a network path which is working fine for all of us.
We download our packages via, unzip and copy the contents to the networkdrive.


@m.rijsmus this is the method I used successfully in the past. The empty app data folder is important as conflicting package versions can cause issues.

Thanks @john_pierson - I had heard of this option but never thought of changing our process as it had been working so far.
Will chat to our IT guys, see if it’s something that we can achieve as well.

1 Like

I faced the same issue and found a different workaround.

By copying the shared package folder to my local drive and pointing on this file, I get access to all the packages.
Then I point back to the original shared location on the network drive.

This is just a workaround and I hope a real solution will come up in a future release.