texupport

I’ve been meaning to write about this for some time now, but I just haven’t had the time until now…

I rolled out Civil 3D 2010 to several offices in October of 2009.  Starting in May of 2010, I started to receive periodic reports of 2010 raising Fatal error e0434f4dh at 7c812afbh immediately after it was launched.  In these cases, no drawing files were opened and nothing out of the ordinary took place.  After running Civil 3D succesfully for weeks or months at a time, a user can simply double click on the C3D icon and can’t proceed past the fatal error.

When I submitted a CER on this, Autodesk’s stock response was to let the secondary installer reinitiate the user profile.  Unfortunately, this is time consuming and it’s usually not a simple task for an average end user.  Knowing that the secondary installer just installs clean registry entries and appdata, I decided to dig a little deeper.

Before running the secondary installer, I exported everything under HKCU\Software\Autodesk\AutoCAD\R18.0 to a .REG file so that I could compare a fresh copy of a user profile to one which was creating the fatal errors.  Then, after creating a clean user profile, I chopped the .REG file in half using a text editor.  Then I repeatedly restored half of the .REG file, and half again, until the fatal errors started to reappear.  It took some time, but I eventually zeroed in on the following key:

HKCU\Software\Autodesk\AutoCAD\R18.0\ACAD-8000:409\WebServices\CommunicationCenter\LastUpdateTimeLoWord

By resetting this value to 0, the fatal errors went away.  Over the past ~8 months, I’ve fielded several dozen reports of this fatal error, and in all but on case, setting the above key to 0 solved the issue immediately.  I’ve even helped friends at other firms use the same workaround successfully.

One of our other offices also runs vanilla AutoCAD 2010 and I’ve seen similar reports, albeit less frequently.  The same dword for AutoCAD 2010 can be found here:

HKCU\Software\Autodesk\AutoCAD\R18.0\ACAD-8001:409\WebServices\CommunicationCenter\LastUpdateTimeLoWord

There is one unexplainable aspect to this workaround.  After I had seen several instances of this behavior, I started to document the value that was stored in LastUpdateTImeLoWord.  For example, on August 16, 2010, one user couldn’t launch Civil 3D 2010, and I noted that LastUpdateTimeLoWord was set to 1281970257 (decimal) in his registry.  I reset it to 0 to get him back up and running.  However, manually setting LastUpdateTimeLoWord to 1281970257 (decimal) on any other system, or under any other user profile doesn’t seem to cause fatal errors all by itself. 

I should note that over in the Autodesk discussion groups, there are several reports of similar fatal errors at startup, but at different addresses.  Your mileage may vary if you try this workaround for any fatal errors other than Fatal error e0434f4dh at 7c812afbh

We haven’t deployed 2011 in production yet, and I haven’t seen the same fatal errors on my test systems.  I can say that I have had Civil 3D 2011 get into an “not responding” state immediately after launching, but without any fatal errors.  When I saw this, I set the equivalent dword to 0 (HKCU\Software\Autodesk\AutoCAD\R18.1\ACAD-9000:409\Webservices\CommunicationCenter\LastUpdateTimeLoWord) and then I was able to run C3D 2011 successfully.  I admit, though, that I haven’t seen enough cases of this on 2011 to be able to say definitively whether or not this key was responsible.  I may have just jumped the gun on killing the acad.exe process.

To summarize, to clear out this particular error in the 2010 versions, copy the following to a text file with the .REG extension and then double click on it when logged in as the affected user:

For Civil 3D 2010:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R18.0\ACAD-8000:409\WebServices\CommunicationCenter]
@=""
"LastUpdateTimeLoWord"=dword:00000000
"LastUpdateTimeHiWord"=dword:00000000

For AutoCAD 2010:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\R18.0\ACAD-8001:409\WebServices\CommunicationCenter]
@=""
"LastUpdateTimeLoWord"=dword:00000000
"LastUpdateTimeHiWord"=dword:00000000

Since rolling out 2009 to a large userbase, we have encountered several drawing files which contain specific layouts within which any viewport will not show filled 2d solids properly. This behavior seems to be specific to AutoCAD 2009. The same drawing files behave as expected in AutoCAD 2008 (and, presumably, earlier releases).

Although fillmode is turned on, a viewport within an affected layout will show 2d solids like so:

Of note:

• fillmode is set to 1
• All viewports are set to 2d wireframe / hideplot is turned off in all of the viewports
• I do have raster design 2009 installed. Neither the “filled object hotfix” nor SP1 corrected the problem
• An example drawing can be found here: http://www.texupport.net/acad_examples/fillmode.dwg

Workarounds: Recreate the entire layout, including the viewports and any paperspace annotation.
First Appeared: AutoCAD 2009
Status as of AutoCAD 2009 version 3.1: Still reproducible.

Starting with AutoCAD 2009, the most recently used files list is designed to list both DWG and DST files.  Unfortunately, once nine (cumulative) DST files have been opened by one user, then the most recently used documents list will no longer contain drawing files. 

Workarounds:
I wrote this command to completely reset the MRUF list.  This will remove all entries from the list.  Over time, be prepared for it to be populated by nine DST files again.  When that happens and it gets to be too annoying, simply re-run the command.  (Note: I’ll add the LSP file to the downloads section ASAP.)

;;Reset Most Recently Used Files
;;This utility can be used to clean out the mess that 2009 and 2009v2 leaves in
;;the Most Recently Used Document list after opening nine or more DST files
;;absolutely no warranty
;;feel free to modify as necessary
;;I use this only periodically.  I run it manually when my Recently Used Files list gets filled up with DST files.
;;v2008.12.01
(PRINC “Reset Most Recently Used Files (rmruf) v2008.12.01 – www.texupport.net“)
(DEFUN c:rmruf (/ regkey mruf)
 (SETQ mruf (GETENV “MRUFilesToList”))
 (SETENV “MRUFilesToList” “0″)
 (SETQ regkey (STRCAT “HKEY_CURRENT_USER\\” (VLAX-PRODUCT-KEY) “\\Recent File List”))
 (VL-REGISTRY-DELETE regkey)
 (SETENV “MRUFilesToList” mruf)
 (PRINC “\nMost Recently used files list has been reset.”)
 (PRINC)
) ;_ end-defun

First Appeared: AutoCAD 2009
Status as of AutoCAD 2009, version 2: Still reproducible

When  creating a sheet set template by placing a DST file in the SheetSetTemplatePath location, the file must absolutely have an extension of .dst (case sensitive).

If an uppercase character exists in the extension, the sheetset template appears with the extension in the listbox and the system will then search for YourTemplateName.DST.dst. 

When it doesn’t find the template, a “File Not Found” dialog reports “Cannot find the specified sheet set data (DST) file.”

Workarond:
Create sheet set templates with a lowercase dst extension.

First Appeared: Unknown
Status as of AutoCAD 2009 version 3: Still Reproducible.

When using a multileader style with the leader connection point set to “middle of text,” the text attachment point jumps to the “middle of the top line” when any field is added to the text.

Figure 1 – Middle of Text justified mleader

Figure 2 – The same mleader with a field added

Thanks to Christian Billiot for submitting this report.

Workarounds: None Known

First Appeared: AutoCAD 2008
Status as of 2009: Still reproducible

Under certain circumstances, the hatch command’s island detection feature does not work when mtext entities are contained within the area to be hatched.

Steps to reproduce:

   1. Create two mtext objects with this text (include a return after each word):  test centered text
   2. Set the width on both mtext objects to 0.
   3. Change the first mtext object to be middle centered justified.
   4. Edit the second mtext object:
   5. Select All
   6. Select the “Center” icon on the Text Formatting toolbar

   7. Both mtext objects look the same at this point.
   8. Draw a rectangle around each mtext object.
   9. Hatch inside each rectangle (allowing island detection).
  10. While the island detected around the middle justified text is correct, the border around the center justified text is incorrect.

Workarounds:
Either use middle justified mtext entities or do not use zero with mtext entities.

First Appeared: Unknown.  Bug didn’t exist in 2004, but is easily reproducible in AutoCAD 2008.
Status as of 2008SP1: Still reproducible

Submitted By: TommieR

Ever since bhatch was introduced in R13, it has had trouble finding the boundary of many areas which are bound by arcs or polylines with arcs.  This bug seems to be more troublesome the farther the linework is away from the UCS origin.  It appears to be worse still when the linework is far from the WCS origin (such as any geospatial drawing).  Over the past 14 years, the user community has come up with numerous workarounds to coax results from the bhatch command.  Unfortunately, no single workaround works in all cases.  Furthermore, none of these workarounds make sense to younger users who have never had to massage results from their software and have grown to expect applications to “just work.”  These workarounds are documented below.
 

Workarounds:

• If the linework is polylines, sometimes it helps to explode them before hatching
• If the linework is lines and arcs, sometimes it helps to convert them to polylines before hatching
• Sometimes it helps to temporarily set the UCS closer to the current view *
• Sometimes it helps to temporarily move the linework closer to the WCS origin
• Sometimes it helps to continuously cut the figure that won’t hatch into halves and hatch each half until a “leak” is found
• You should always to check the entities in question for an “extrusion direction” and if they have one, remove the extrusion direction with the express tools FLATTEN command. 
• HPGAPTOL almost never works

First Appeared: When bhatch was introduced in R13 (1994).  It’s possible that the hatch command from previous releases exhibited the same symptoms, but I simply can’t remember.
Status as of 2008 SP1: Still reproducible.

* I have written a short lisp command which automatically sets the UCS close to the current view, runs the bhatch command, and then sets the UCS back.  Although it still fails in many of the same situations that cause the “out of the box” bhatch command to fail, it definitely does a better job than the default command in many cases.  In particular, it sheilds the users from quite a few hatch errors when working in geospatial drawing files.  The code is as listed below.  I’ll add it to the downloads section as time permits.

;; bbh.lsp (Better BHatch)
;; ralph sanchez (rsanchez at texupport dawt net)
;;
;; As most users know, AutoCAD has trouble hatching anything but simple figures when working far from the WCS origin
;; The user community has come up with several workarounds and this code attempts one of the most common.
;; In short, it will temporarily change the UCS to the current view before executing the bhatch command.
;; As with all of the workarounds, it is not perfect and does not work in many situations.
;; It does, however, work better than the default bhatch command.
(DEFUN c:bbh (/ ucsorg ucsx ucsy)
  (DEFUN savars (sv0 / x)
    ;;excellent savars/revars functions from paul turvill
    ;;(prevents user ESC from killing variables)
    (COMMAND “._undo” “begin”)
    (SETQ svx1  nil
   olderr *error*
    ) ;_ end-setq
    (FOREACH x sv0 (SETQ svx1 (APPEND svx1 (LIST (LIST x (GETVAR x))))))
    (SETQ ucsorg (GETVAR “UCSORG”))
    (SETQ ucsx (TRANS (LIST 1 0 0) 1 0))
    (SETQ ucsy (TRANS (LIST 0 1 0) 1 0))
    (DEFUN *error* (msg) (revars))
  ) ;_ end-defun
  (DEFUN revars (/ x)
    (SETQ *error* olderr)
    (FOREACH x svx1 (SETVAR (CAR x) (CADR x)))
    (SETQ svx1 nil)
    (COMMAND “._ucs” “3p” (TRANS ucsorg 0 1) (TRANS ucsx 0 1) (TRANS ucsy 0 1))
    (PRINC)
    (COMMAND “._undo” “end”)
  ) ;_ end-defun
  ;;******************************************************
  (savars ‘(“cmdecho”)) ;’saves variables to be reset later
  (SETVAR “cmdecho” 0)
  (COMMAND “._ucs” (GETVAR “vsmin”) “”)
  (INITDIA)
  (COMMAND “bhatch”)
  (WHILE (= (LOGAND (GETVAR “cmdactive”) 1) 1) (COMMAND pause))
  ;;****************************************************** 
  (revars)
  (PRINC)
) ;_ end- defun

After joining lines or polylines within the PEDIT command, the SPLINE option can’t be run until the command is ended and reexecuted.

Steps to reproduce:

• Draw three lines which meet end to end
• Enter PEDIT (if peditaccept is turned off, hit “y”)
• Select J to join the segments
• Select S to spline the resulting polyline
• Notice that the command is exited

Workarounds: Exit the PEDIT command after joining the segments, then reexecute PEDIT and select S to spline.

First Appeared: 2007? (This bug is definitely not evident in 2004 and is known to exist in 2007.  Its status in 2005 and 2006 is unknown)
Status as of 2008 SP1: Still reproducible.

Thanks to Opie for submitting this report.

In properties for the an annotative dimension entity, change the “text movement” property to “move text, no leader,” then save, close and reopen. After reopening, grip edit the text portion of the dimension, and notice that the “text movement” property changes back to “move text, add leader.”

My testing has confirmed this bug in C3D, LDT and MAP 2008, but not necessarily AutoCAD 2008.

Workarounds: Use a dimension style set to “move text, no leader,” rather than using the property override.

First Appeared: Map 2008, C3D 2008, LDT 2008
Status as of 2008 SP1: Still reproducible.
Status as of 2009: (unknown)

When copying with COPYBASE and attempting to paste using PASTEORIG, the copied entites do not appear.

This only appears to occur when using COPYBASE with PASTEORIG. Keep in mind that if you will be executing PASTORIG, then using COPYBASE to specify the entities will present a useless prompt for base point.

While its true that this can at least be interpreted as user error, the software should at least report the user error in a message box or at the command line.

Workarounds: Use COPYBASE with PASTECLIP. Use COPYCLIP with PASTEORIG.
First Appeared: AutoCAD 2006
Status as of 2008 SP1: Still reproducible.
Status as of 2009: (unknown)

In Land Desktop 2004, there is a well documented problem where undo just stops working when it encounters an INTELLIZOOM operation and reports that there is “nothing to undo.” I’ve researched this issue thoroughly and, despite the fact that many people have experienced it, it appears that there was never an official word from Autodesk about it.

For what its worth, when I’ve seen this behavior, the QSAVE command causes several UNDO commands to perform automatically. This appears to have been an equally frequent issue among users with no publicly documented solution.

From my troubleshooting, I’ve determined this much:

• When starting a fresh drawing, UNDOCTL = 5. After issuing several standard AutoCAD commands, UNDOCTL is still set to 5. Likewise, before issuing any undo commands, UNDOCTL is still set to 5. After undoing a few commands, undo reports “nothing to undo” when undoes an INTELLIZOOM operation. At this point, UNDOCTL = 1.
• It’s not tied to the hardware or OS, since other users logging in to the same computer can undo just fine. It has to be tied to the windows profile.
• It’s not related to the affected users AutoCAD profile, because I can export her profile to an ARG file, and then import it to another station, where UNDO works just fine.
• It’s not caused by any 3rd party software, since the affected user isnt running any add-on apps.
• Running a dummy “check points” does not correct this behavior
• A repair install does not correct this behavior.

For reference:
• http://discussion.autodesk.com/thread.jspa?threadID=369777
• http://management.cadalyst.com/cadman/article/articleDetail.jsp?id=101912
• http://discussion.autodesk.com/thread.jspa?messageID=4584
• http://discussion.autodesk.com/thread.jspa?messageID=5296

Workarounds: No reliable workarounds for 2004

First Appeared: AutoCAD / Land Desktop 2004

Current Status: Undos flakiness has gotten gradually better with each subsequent release. To date, however, nobody has provided a reliable solution when 2004 starts to behave this way.

Starting in 2008, the search function in VLIDE’s help doesn’t work.

Workarounds: None known. What else can be said about this? It should work, but it doesnt.
First Appeared: AutoCAD 2008
Status as of 2008 SP1: Still reproducible.
Status as of 2009: (unknown)

AutoCAD 2008′s new Annotative property for BLOCKS, TEXT, HATCHes, and DIMENSIONs does not work with AutoLISP’s (ENTMOD) function. Since (ENTMOD) is unaware of the Annotative property, applying that function to any entity list will in effect kill the Annotative properties and instances of that entity.

Workarounds: Rewrite all of your code and Autodesk’s Express Tools code? (File under – no reasonable workaround)
First Appeared: AutoCAD 2008
Status as of 2008 SP1: Still reproducible.
Status as of 2009: (unknown)

After adding a custom folder to AutoCADs “device driver search path” (ACADDRV), 3DCONFIG may report that there are no hardware drivers available. This only occurs when the custom directory is listed before the out of the box location for drivers.

Workarounds: Add your custom DRV folder after the “out of the box” value in Options -> Files or:

(setenv "ACADDRV" ... )

Replace … with the desired folder(s).

First Appeared: AutoCAD 2007
Status as of 2008 SP1: Still reproducible.
Status as of 2009: (unknown)

In Land Desktop 2008, there appears to be an issue with loading shape files in some drawing files. When opening files which contain complex linetypes, the accompanying shape files are not loaded. Consequently, complex linetypes appear to be dashed.

Workarounds: Manually load the linetypes after opening the drawing. This can be automated by adding the appropriate code to your acaddoc.lsp. The following snippet is an example of how you can load all of the linetypes in specified LIN files. If you’re a clean freak, though, you would probably want to purge afterwards. This is just a workaround, though. Hopefully Autodesk will provide an actual fix.

(SETQ experto (GETVAR "expert"))
(SETVAR "expert" 3)
(SETVAR "cmdecho" 0)
(PRINC "ACAD.LIN file ... ")
(COMMAND "._linetype" "l" "*"  "acad.lin" "")
(PRINC "loaded")
(PRINC "AECCLAND.LIN file ... ")
(COMMAND "._linetype" "l" "*"  "aeccland.lin" "")
(PRINC "loaded")
(PRINC "COMPANYCUSTOM.LIN file ... ")
(COMMAND "._linetype" "l" "*" "COMPANYCUSTOM.lin" "")
(PRINC "loaded")
(SETVAR "expert" experto)
(SETQ experto nil)(PRINC)

First Appeared: Land Desktop 2008
Status as of 2008 SP2: Still reproducible.
Status as of 2009: (unknown)

A TEXT entity (not MTEXT), not at 0.0 rotation, that contains text and a FIELD, whose properties include either a width factor that does not equal 1.0 -or- a obliquing angle that does not equal 0.0 – displays incorrectly.

Thanks to RK McSwain for submitting this report.

Workarounds: Use MTEXT
First Appeared: AutoCAD 2008
Status as of 2008 SP1: Still reproducible.
Status as of 2009: (unknown)

Frequently after doing extensive 3DORBITing, you lose the ability to quicksave (CTRL-S, save icon, qs). The command line reports: “yourfile.DWG has a command in progress.”

Workarounds: Type SAVE at the command line to save, then close and reopen the drawing.

First Appeared: AutoCAD 200?
Status as of 2008:Still occurs.
Status as of 2009: (unknown)

Under certain circumstances, AutoCAD’s undo command becomes very sluggish. This is frequently caused by a dead end windows shortcut somewhere in the support path or in the locations specified in the ACADDRV, PrinterStyleSheetDir, PrinterDescDir, PrinterConfigDir environment variables or any other location that AutoCAD is configured to search for files.

Workarounds: The most common dead end shortcut is the “Add A Plotter Wizard” which can be found in the directory specified by environment variable PrinterConfigDir. You can retrieve this variable with the following AutoLISP code.

(GETENV "PrinterConfigDir")

Find the offending shortcut and either delete it or point it to a location that everyone will have access to.

Often, this is caused by inexperienced CAD Managers copying the entire PrinterConfigDir from their C drive to a network location. Regardless of their experience level, there really is no practical reason for AutoCAD to search within the PrinterConfigDir when executing the UNDO command or any other command not related to plotting

First Appeared: AutoCAD 200?
Status as of 2008: Still occurs.
Status as of 2009: (unknown)

In AutoCAD 2008, you may notice that publishing from the Sheet Set Manager causes fatal errors in some cases. So far, the user community hasn’t established why some sheet sets cause fatal errors while others do not. What has been established is that sheet sets which cause fatal errors at publish time will always cause fatal errors as long as publishcollate is set to 1. Setting publishcollate to 0 seems to clear up the fatal errors.

Setting publishcollate to 1 is actually a very useful feature when creating PDFs and PLT files, so remember that it’s a system (registry) saved variable that you may have to change back and forth manually to accommodate different situations.

Workarounds: As mentioned above, set PUBLISHCOLLATE to 0
First Appeared: AutoCAD 2008
Status as of 2009: (unknown)

Occasionally, when you try to bind an xref to your current drawing, one or more xreffed files do not bind. Sometimes an error is reported; other times there is no error but the operation just doesn’t complete.

Workarounds:

1. In each problematic child drawing, run the WBLOCK command
2. Select ENTIRE DRAWING as the source
3. Select the current folder as the output location
4. Close the child drawing
5. In windows explorer, navigate to your drawings directory
6. Rename your original child drawing to something like originalfilename.sav
   (so you can go back to it if you have to)
7. rename the drawing file created by wblock (from step 3) to your original child drawing’s filename
8. open the parent drawing
9. try binding the child drawing that you just worked with

First Appeared: AutoCAD 2000?
Status as of 2008: Still occurs.
Status as of 2009: (unknown)

Starting with the 2007 releases, Autodesk included an HDI PDF driver along with AutoCAD and its vertical applications. This was a big selling point since many customers were misled into believing that they wouldn’t have to purchase 3rd party PDF writers for use with AutoCAD. Unfortunately, the “DWG to PDF” driver (pdfplot9) has several very limiting factors that make it useless to many if not most AutoCAD users.

1. It does not observe lineweights when using true type fonts.
2. When publishing multiple sheets, entities from any given layout may actually appear on the wrong page in the resulting PDF file(s).
3. The origin and margins are very limiting.

Despite these shortcomings, Autodesk still lists PDF output on their feature checklist, but the customers still have to look for a 3rd party solution.

Workarounds: Several users have reported good luck with various PDF drivers, including Adobe Acrobat, PDF995, Acroplot, Jaws, and many others.

If it’s hard to justify the added expense for a feature that AutoCAD is already supposed to include, PDFCreator is a nice Windows PDF driver.

First Appeared: AutoCAD 2007
Status as of 2008: Still reproducible.
Status as of 2009: Still reproducible.
Status as of 2010: Much imporved.

In AutoCAD 2008, when you try to add or remove toolbars, menus, palettes or panels to your workspace from within the CUI editor, it appears to save the changes when you exit the editor. When you’re back in the drawing window, however, none of your workspace edits are actually saved.

Workarounds:
This appears to be directly tied to turning on “Automatically save changes to workspace.” If “automatically save changes” is turned on, then the CUI editor does not work. If it is turned off, then editing in the CUI editor does work.  To check this setting, you must first exit the CUI editor and then run the WSSETTINGS command.

First Appeared: AutoCAD 2008
Status as of 2009: Appears to have been fixed.  Tough luck for all of the 2008 users who aren’t on subscription.

If you use xrefs regularly, scales from your xrefs can start to appear in your current drawing like this: 1″ = 30-0″_XREF_XREF_XREF

Workarounds: To reset the scale list in your drawing, run the following at your command line:

-scalelisteditRYE

To reset the scale list in every drawing that you open, put the following line into your acaddoc.lsp file.

(command "-scalelistedit" "R" "Y" "E")

First Appeared: AutoCAD 2008
Status as of 2008 SP1: Patched

Regardless of whichever PDF writer you use, it is very common for the resulting PDF files look fine on your screen, but not observe wipeouts when printed to paper.

Workarounds: Before sending your drawing to the PDF printer, change the color of all of the wipeouts to a color that wont show up on the printed page. Using QSELECT, you can select all raster images, then explicitly deselect any actual images. Then in the properties flyout, change the color by selecting the true color tab, and specifying RGB values of 255,255,255. I’ve also written a short command to do this and I will upload it as time permits. Email me if you’re interested.

Mike Ishman has reported that Jaws PDF Creator does not exhibit these symptoms.

Since inserting DXF files with the normal INSERT command causes so many problems in 2005+, a seemingly valid workaround would be to run DXFIN via AutoLISP like so:

(command "dxfin" "x:/mypath/myfile.dxf")

Unfortunately, in AutoCAD 2006, running the above statement causes the UNDO command to stop working, regardless of how UNDOCTL is set.

First Appeared: AutoCAD 2005/6?
Status as of 2006 SP1: Still reproducible
Status as of 2010: (unknown)