texupport

Download file: alab.zip  

Since corridor files can get pretty busy, a good method to keep assemblies organized is to add mtext “labels” with fields that pull the name out of the assembly object.  This process can be a little tedious since the user has to place the mtext/field, point it to the proper object, select the appropriate field, and repeat that for each assembly.  The end result looks something like this:  

Mtext fields point to each assembly and display the name value.

In order to make the labeling process a little easier, I’ve written a short command to label one or more assemblies, with fields, using only a a single command.  To use this command, download this file and unzip it.  Then follow the instructions from the alab-readme.txt file as shown below:  

Instructions:  

• Copy the DLL for your version of Civil 3D to a local drive
• Run Civil 3D and load the DLL with the NETLOAD command.
• For advanced users, it can also be automatically loaded by adding (command “netload” “c:/yourpath/alab”) to your acaddoc.lsp file.
• Execute ALAB at the command line
• Select one or more assemblies

Notes:  

• Unless you’re very familiar with configuring the dotnet framework, this DLL must be stored on a local drive.  With the stock dotnet configuration, dotnet DLLs will load into your Civil 3D session from a network volume, but they will cause fatal errors when executing the commands.
• The labels are drawn on the current layer, using the current text style.
• Versions for Civil 3D 2010 (alab-2010.dll) and Civil 3D 2011 (alab-2011.dll) are included in the zip file.  You only need to load the DLL for your version of Civil 3D.
• This command is free to use.  There are no warranties.

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