Help! We just installed Civil 3D 2020 (and also updated to 2020.2) (as well as an update to Windows 10).
We have noticed on most machines that when a drawing has unloaded XREFs, when a save is performed, it will "bog down" and take a long time. It also has the "Synchronizing references" bar pop up repeatedly in the bottom right.
While looking into this a little more, we also noticed that the .DWL and .DWL2 files were opening for the unloaded XREFs when we hit save.
We have the following variables set to:
Are these even variables we should be looking at? Which other variables should we check?
If we reload the XREFs and qsave, the save is almost instant. Any help on this would be greatly appreciated.
Solved! Go to Solution.
Solved by JeffPaulsen. Go to Solution.
Hi @TonyLeggieri3279 ,
Thank you for posting this in the Autodesk Forums! I see you have an issue Civil 3D 2020 when attempting to save with unloaded XREF's. How long is it taking to save files with unloaded XREF's? I would take a look at this article: Long save time when working with XRefs in AutoCAD and see if the solutions fix the issue. It looks like you have already adjusted the variables accordingly. For full transparency, we do have a recent known issue with long save times with unloaded XREF's. Once reloaded the file saves much quicker. Before attesting this as the issue, I would like to test your file. Can you attach a zip-file with the drawing as well as the XREF's? You can send it to me directly if you do not want it public facing.
Nate,
We uninstalled service pack 2020.2 and the issue seems to go away. Hopefully it will be resolved in 2020.3. We made sure to run the Pipe Network hot fix on the machines we are taking the service pack off of.
There was not 1 specific drawing but rather any drawing with unloaded XREFs. And it happened on multiple machines.
Thank you for the response.
Yes this is the recent known issue we are seeing. I am going to attest your case to development for their review. Thank you for taking the time to identify this and post his in the forums. Hopefully we can get this rolled out in a fix soon!
Nate,
I confirmed that the long save issue goes away after removing the C3D 2020.2 update. After removing the update I am left with version 13.2.890.0 Autodesk Civil 3D 2020. Where can I download Update 2020.1?
I wanted to check in on this issue. I have spent multiple hours problem solving this issue. We have recent started working towards upgrading to 2020. Luckily I came across this post. This is 100% the issue with unloaded xref's. I have tried on multiple machines and drawings. Issue saving every time. Looking forward to a fix for this one.
@Nate Add us to the list of firms that are suffering the same issue: Files with unloaded xrefs used to save instantly on 2019. After upgrading to 2020 they are now taking minutes to save. If we reload the xrefs, the file saves instantly.
Civil 3D 2020.2
AutoCAD 2020.1.2
Have there been any new developments on a fix?
What I've noticed is that civil3d 2020 (I've tested it personally on 2020.1 and 2020.2) is attempting — successfully or unsuccessfully, I'm not sure — to open a series of drawings related to the unloaded XREFs. XREFs that are loaded do not exhibit this behavior; when the XREF goes from unloaded to loaded it opens some number of drawings. I set up a :vlr-dwg-reactor to try to look at what's going on and it looks something like this:
Command: qs QSAVE
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215b36b77a8> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Engineering\ConDocs\Sheet-Files\C-4.X - Grading and Drainage.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215b6df1f58> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XG-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215b95a3da8> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XC-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 000002159ff29be8> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XG-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215bf311118> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XG-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215b2e5c1b8> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XG-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215b2d1e7c8> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XG-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215bae22d78> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XT-0238-01-RS15.dwg)
Open:
; Reaction: :VLR-dwgFileOpened; argument list: (#<VLR-DWG-Reactor>)
(#<VLA-OBJECT IAcadDatabase 00000215b2fc5558> N:\0201\0238-01-RS15-Emerald-Ridge-Apartments-Entitlement-Con-Docs\Xrefs\XUTHOMA-0238-01-RS15.dwg)
The interesting parts are it opens the same drawing more than once, and it's opening some drawings that have no Dynamic References for what I previously thought this behavior was attached to. I've had a similar experience with 2018 so I'm wondering if these two things are related, and how I can prevent this behavior from happening.
So here's another interesting tid-bit with xrefs. I had a client with a problem that when xreffing in a drawing, It xreffed a completely different drawing but with the same exact name from a totally different folder.
So then, further researching... they have their Temporary Xref Path in options set to C:\Temp
Looking in that folder, they had 2 referenced drawings with the same drawing name suffix, but once wiping out that folder, and trying to xref the correct drawing, the drawing in the correct location came in as it should.
So there's definitely, something happening in the background with xrefs that was not like it was.
It looks like Civil 3D 2020.3 was released.
Unfortunately, I don't see anything in the list of "fixed issues" that addresses the slow saving issue.
Are you able to confirm whether or not these issues were addressed, @nate.philbrick? I know sometimes things are fixed behind the scenes that users are never made aware of in these docs.
I installed 2020.3 today and I still have the delay with unloaded xref's.
Hi All,
Thank you for your continued contribution in the forums. Civil 3D 2020.3 was released today. According to the Fixed Issues, I do not see a fix for the slow save files with unloaded XREF's. Development is monitoring this thread. If you want to contribute more to this issue, please create a support request where we can attest these individual instances to development for their review. I hope we get a fixed rolled out for this soon!
So I believe I found a solution...
In Windows 10 user permissions are not always full on folders on your computer.
Close Civil 3D...
In Windows explorer, right-click on folder
Set the login Users temporary xref location folder to have full permissions.
In my case C:\temp. see attached image on how to allow full permissions.
This solution does not work for me unfortunately.
My error message when all XREFs are unloaded is as follows:
"No matching and loaded xref names found."
When I have drawings with Data References loaded, I can very briefly see a "synchronizing data references" in the bottom right whenever I am saving.
Thanks,
Have you recently cleaned out your temporary xref folder location with Civil 3D closed?
Just a thought.
I switched it to C:\Temp right before I tested. There was nothing in the folder.
Folder permissions doesn't work for me either. Same issues, slower save with unloaded xref's.
Interesting! one of my clients has about 30 users, and there were instant results in the saving time after changing permission settings to allow full access to the Temporary Xref folder in Windows 10.
Like minutes to seconds.
To further explain how this came about was an earlier post on problems with MAP FDO connection using WSM that was not working. Once this change was made it made a world of difference.
Curious if others are benefiting from this.
Also curious if those that it does not work for are using the default path for temporary xref path or have it custom as in C:\temp. Also am curious if xrefs are attached or overlaid. My clients xrefs are overlaid, not attached.
The file I used in the screencast above has both Attach and Overlay xref's.
We do have a custom folder mapped for AutoCAD "C:\ACAD-TEMP"