AutoCAD Large File Size Problem

Isaac Asimov While I generally find my own motivations in life aligned with Isaac Asimov’s quote which declares that “the true delight is in the finding out rather than in the knowing“, there have been times troubleshooting certain issues where I found myself wishing I just knew what was wrong.

One such recent issue involved multiple clients all of whom exhibited the same mysterious crisis: having a user base working with DWG files that kept getting increasingly larger. At a cursory glance, there seemed to be nothing wrong with these drawings. Audits came up clean. Purging did nothing to reduce the file size. Even blocking out the drawing into a clean template made no difference. All this to say that I found myself asking what could be possibly done to not only identify this problem but resolve it once and for all?

HOW BIG IS BIG?
Identifying certain characteristics of a problem usually helps single out its cause, much like I imagine a doctor’s diagnosis would be based on a patient’s symptoms. Examining a sample drawing that a client sent me, I noticed what appeared to be a small drawing with very little line work weighing in at 7.38MB. As I previously mentioned, I went through what I consider due diligence whenever troubleshooting an issue related to mysterious drawing behavior; checking the number of scale lists (SCALELISTEDIT), ensuring that there aren’t excessive registered applications (REGAPPS), purging any unused styles (-PURGE), and auditing the file for corruption (AUDIT), however none of these methods resolved the bloat problem nor did they identify the source of the cause.

THINKING OUTSIDE THE BOX
One of the benefits of being a long time Civil 3D user is knowing about some of the built-in Map 3D Features that enable users to attach an existing drawing to an a empty file as a database. Using this feature one can define and execute queries related to objects in an existing drawing and then draw them in a new one. This is usually my go-to step in fixing drawings and sure enough going through this process reduced the file size tremendously. This allowed me to assist our clients by cleaning one or two problematic drawings, but did nothing to allow users to help themselves, mostly since this problem seemed to happening exclusively to our architectural clients who typically don’t have a license of either Civil 3D or Map 3D.

It was through some extended dialog with the client that the next piece of the puzzle fell into place, namely the indication that when opening one of the affected drawings in an earlier version of AutoCAD (2010 to be exact), a proxy warning dialog window appeared. When examined, the dialog window finally gave us the lead we needed.

PROXY WAR
proxy-dialog-windowLooking at the sample dialog window to the left you will see a very large number of proxies, approximately two hundred thousand, which would explain the excessive bloating seen in the file size. The proxy warning targeted the missing application as AcDgnLS, which exposed that the offending objects likely came from Microstation (the tell being that Microstation files are designated with a DGN extension). Further research would later precisely target DGN LineStyles . For an extensive understanding of the underlying purpose of these proxies, please read Kean Walmsley’s Through the Interface post named Purging unwanted DGN linestyle data from an AutoCAD drawing using .NET and all its derivative posts located at the end of the article.

While this at least revealed the problem , it still left me with no readily accessible tool to rid the drawing of these proxies. Opening a case with the Autodesk support team confirmed this fact and at the time the case was open, the only strategies were the previously mentioned workaround using Civil 3D/Map 3D as well as two other alternatives, the first using DXFOUT/DXFIN and the second utilizing AutoCAD 2010.

THE FIX
Fortunately, as of August 2nd, 2013 the AutoCAD DGN hotfix has come out that specifically addresses this issue. In summary all that is required is replacing a file in the root of the application folder (AcDgnLS.dbx) and then running AutoCAD and using the NETLOAD command to load a DLL (DgnLsPurge.dll). Once the DLL is loaded, type in DGNPURGE at the command line and press RETURN to purge out the objects causing file bloat. As a benchmark, I performed the purging process on a client’s file and it took 2 minutes 10 Seconds to clean. Below is a typical message that is displayed after the purge is complete (total number of purged objects will vary).

DGN Purge

 

 
In addition, I would suggest running a -PURGE command to purge REGAPPS and ALL as well as using the AUDIT command. Combined with the DGNPURGE, those actions reduced the sample file down from 8.8MB to 1.3MB. In another instance with a different client’s file, the purging process reduced a drawing to less than 1% of its original size, from 7.5MB to .062MB.

According to the hotfix, computers patched with the new DBX file “will also prevent future occurrences of the file bloat issue from occurring” so it’s imperative that every user is patched and that any drawings coming from outside consultants are cleaned up before being inserted into your own projects.

EPILOGUE
If you want to incorporate the NETLOAD of the DGNLSPURGE.DLL command into your start up lisp routine so it loads on every workstation once you’ve rolled out the DBX file firm-wide, you can add the following code to your acad2014.lsp (or acad2013.lsp) as it runs the first time AutoCAD is launched and will allow you to run the DGNPURGE command without manually loading the DLL first.

(command “netload” “C:\\Program Files\\Autodesk\\AutoCAD 2014\\DgnLsPurge.dll”)

Lastly, I have seen some clients run the DGNPURGE command and have error messages appear, such as the following:

  • Unable to erase stroke (AcDbZombie Object): eNot Allowed For This Proxy
  • Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly ‘file:///C:\Program Files\Autodesk\AutoCAD 2013\DgnLsPurge.dll’ or one of its dependencies. Operation is not supported

The solution for both these messages was to force load the AcDgnLs.dbx file by adding it to the Startup Suite. After doing so the DGNPURGE command worked as expected.

EDIT 01 (09/03/13)
As of September 3rd, Autodesk has released an additional Hotfix for AutoCAD 2012 and related vertical products.

EDIT 02 (09/10/13)
If you have followed my suggestion above regarding loading the DgnLsPurge DLL automatically and would also like to run DGNPURGE on every drawing you open to help “automate” the cleaning process, I would suggest adding the following code to the end of your acad*doc.lsp (where the asterisk pertains to the release year e.g. 2014) as this lisp runs the every time an AutoCAD drawing is opened. NOTE: This will slow the opening process for affected drawings as it will launch into the purge command every time it encounters a corrupt drawing (it can take several minutes). Once a drawing is cleaned, subsequent opens will be as quick as they were before adding the code since the purge process returns 0 linestyles to clean out.

;;;
;;; Run DGNPURGE to clean drawings when opened
;;;
(command “DGNPURGE”)

About Steven Costa
Steven Costa has been with Microsol Resources, an Autodesk Platinum Partner, for 9 years and specializes in all things Infrastructure and provides technical support for the Autodesk Infrastructure Design Suite family. He specializes in streamlining the collaborative workflow between the Autodesk Building and Infrastructure family of products with a focus on data exchange between Civil 3D and Revit. He also maintains the Microsol Resources website. In his spare time he dabbles in front and back end web design, scours Reddit for all the latest stories and news, and loves giving recommendations on bars and restaurants in New York City.

24 Responses to AutoCAD Large File Size Problem

  1. German says:

    You are a Genius!!!

    Thanks a lot..

  2. Raul says:

    Thank you, thank you, thank you. This worked for our ‘bloated’ files.

  3. Rhett says:

    I am using LT 2014 and have the same problem, so I downloaded the ‘HOTFIX’ and followed the instructions to copy the extracted files into the installation folder, but when I tried to run NETLOAD it tells me this is an ‘unknown command’ . Is this because my version is only LT and not the full one? Help please…!!

    • Steven says:

      Unfortunately, the fix is only for the full versions of AutoCAD. AutoCAD LT has quite a few differences from the full version, one of them being that it lacks support to load .NET files. If you only have a handful of drawings to clean, I would recommend downloading a free trial of the full version of AutoCAD as that gives you 30 days to go through your files and clean them before you have to purchase the license.

      • Rhett says:

        Hi Steven, brilliant suggestion but when I tried to run the file from the NETLOAD command it spewed the following back to me which I don’t understand at all.

        Command: NETLOAD
        Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly ‘file:///C:\Program Files\Autodesk\AutoCAD 2014\DgnLsPurge.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
        File name: ‘file:///C:\Program Files\Autodesk\AutoCAD 2014\DgnLsPurge.dll’ —> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
        at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
        at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks)
        at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
        at System.Reflection.Assembly.LoadFrom(String assemblyFile)
        at Autodesk.AutoCAD.Runtime.ExtensionLoader.Load(String fileName)
        at loadmgd()

        Any ideas please, this ‘bloating’ is driving me nuts…!!!

      • Rhett says:

        Hi Steven, scrap the above – I have just tried to open the .dll file via NETLOAD and this time it has worked. Many thanks for the response and for saving me hours of work…!!!

  4. Clay Freels says:

    Can someone help me out as to why when I paste the (command “netload” “C:\\Program Files\\Autodesk\\AutoCAD 2013\\DgnLsPurge.dll”) line into my ACAD2013.lsp or ACAD2013DOC.lsp files nothing happens when I reload Autocad? My version is a design suite if that matters. I’ve checked the file path and everything looks fine.

    • Steven says:

      Hi Clay,

      The likely problem is that when you cut and paste from the blog post, the quotations are copied as rich-text rather than simple text. Replace all the “ ” quotes with these “”.

      Steven

  5. Hi Steven,

    Firstly thank you for your article, it has almost entirely solved some sever file size issues we were experiencing in our office. My drafting team had been struggling with files in excess of 150MB’s.

    We’re still having one issue which was not mentioned in your post I was hoping to get assistance on: we must bind all external references into a drawing set of approximately 40 .dwg’s to be forwarded over to our Client. After following this Hotfix, all drawing files appear in their folders at reasonable sizes (1 to 6MBs). However after following the the eTransmit process, and setting it to bind external references, the files saved off in another folder to issuing to the client appear to have been bloated again.

    Is there any way to prevent the drawings from becoming ‘re-infected’ through the eTransmit process.

  6. Shimaa Moustafa says:

    Hi Steven,
    first of all thanks a lot for your useful article, but I still have a problem. when I run DGNPURFE it takes long time ( more than 15 minutes )and the file does not work so it has to be restarted.
    is that normal or because i have done something wrong?

    • Hi Shimaa,

      It’s hard to say without looking at the drawing, but I have seen this occur with very corrupt/large files. How many megabytes is this particular drawing?

      • Shimaa Moustafa says:

        Dear Microsol
        thanks a lot for your response
        it’s around 25MB and it takes about 20 minutes to be DGNpurged, is it normal or i need to do extra thing ?

  7. Arno Mattheus says:

    Hi Steven,

    Your article has been a great help. However on the 4 PC’s I’ve used the hotfix, only two work. The other two give me the following message:

    Purged 16 unreferenced complex linetype records (of 16).
    Purged 0 unreferenced strokes (of 40235).

  8. ahmed says:

    thank you very much its great you save me thanks

  9. Peter Ashby says:

    I had this problem with a drawing after importing a building floor layout, from 32Mb initially I deleted the unwanted layers(laydel) (down to 20Mb) and laymrg ‘d the drawing into 1 background layer, removing all the hatches brought it down to 13Mb, still too big, I trimmed all the background and despite only having 7000 odd entities the file was still over 12Mb, as I use AutoCAD LT 2012, the hotfix wasn’t too helpful, but then I WBLOCK’d the whole drawing into a new file and ended up at 0.6Mb.
    Thanks for the pointers that helped me sort out my problem drawing.

  10. khan says:

    hELLO Steven,
    i have 3D dwg file which is from PDMS. i am using cadworx plant, it is around 40MB. I have to create GA from attaching reference file. lile piping, strucutre, electr, equip.piping and equipmare around 40mb eac. my cadworx program crashes when ataching all the files.

    please help to redue the file size. i used your above suggestion dgnpurge, but nothing happened.

    thanks,
    khan

  11. Hi Steven,

    how to add these code (command “netload” “C:\\Program Files\\Autodesk\\AutoCAD 2014\\DgnLsPurge.dll”) into my ACAD2014DOC.lsp files. i’ve try but i can’t save it.

  12. Laura says:

    Hi Steven,

    Those replaced files work for AutoCAD CIVIL 3D 2014? or they only work for AutoCAD 2014?

    I am using AutoCAD CIVIL 3D 2014 and I did everything you suggested in the article but still when I try to run the DGNPURGE it appears the following message:

    Purged 0 unreferenced complex linetype records (of 0).
    Purged 0 unreferenced strokes (of 0).

    So apparently the file has nothing to purge even though the size is really big.

  13. Simon says:

    Hi Steven, how exactly do you “force load the AcDgnLs.dbx file by adding it to the Startup Suite”? We’ve had this problem for months now and I really would like to come up with a solution for everyone and make sure it does not happen again in the future.

    Thank you!

  14. Mani Prathap says:

    Hi Steven,

    Firstly thank you for your article, I am using Civil3D 2013 version,
    I have tried the DGN Purge, but its taking so much time.I have taken few objects as wblock from a parent drawing which is having 11.4MB.The child wblock also showing same size as 11.4MB.

    While trying DGN Purge on wblocked drawing also its hanging.
    My system is with 64bit, 6GB Ram, Intel core i5

  15. Kevin Redemann says:

    Hi Steven,

    I’ve tried all of the steps for the hot fix and when I load the .dll file using the netload command in autocad I get the below response in my commend line, Any ideas?

    Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly ‘file:///C:\Program Files\Autodesk\AutoCAD 2013\DgnLsPurge.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
    File name: ‘file:///C:\Program Files\Autodesk\AutoCAD 2013\DgnLsPurge.dll’ —> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
    at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
    at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
    at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
    at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
    at System.Reflection.Assembly.LoadFrom(String assemblyFile)
    at Autodesk.AutoCAD.Runtime.ExtensionLoader.Load(String fileName)
    at loadmgd()

    Thank You,

    Kevin

  16. JP says:

    Glad to see this (a year later!); thanks for the clarity and completeness.

    As an FYI, this looks quite a lot like to CDGPURGE, which resolved similar multi-thousand-layer issues in files up to ACAD 2007.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 447 other followers

%d bloggers like this: