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?

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.

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-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.

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.

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
Steven Costa has been with Microsol Resources, an Autodesk Platinum Partner, for 6 years and specializes in all things Civil 3D 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 Architecture and Structure. 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.


  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 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 “”.


  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 ?

Leave a Reply

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

You are commenting using your 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


Get every new post delivered to your Inbox.

Join 445 other followers

%d bloggers like this: