AutoCAD Large File Size Problem

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 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 happen 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
Looking 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).

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 startup 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 FilesAutodeskAutoCAD 2013DgnLsPurge.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 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”)