EATTEDIT Fatal Error Persists - despite reading all Adesk posts

[Anonymous]

We have a problem that has been occurring at a steadily increasing rate - Fatal Errors that result when using EATTEDIT.  The error occurs as soon as the target block is selected whether the command is initiated through the command line or by double-clicking.

The problem first appeared in AutoCAD 2008 running on XP but now occurs in both 2008 and 2011 on both XP and Windows 7.  When the fatal error will happen is unpredictable, even within a single session of AutoCAD and in the same drawing file. 

The error code varies but usually points to a code similar to 63f79d02h.

While the threads I 've read here, including an Autodesk article, seem to point to a trojan as the cause, I can find no files with the D<capital I> L extension on any computer having the problem>  I haven't checked network folders, though.

Here's the really odd part.  When a drawing that has this problem is opened in an Autodesk session with the out-of-the-box Unnamed Profile, all is fine, which seems to point away from it being a virus.  In addition, if a machine that has had no issues opens a drawing that has fataled on a nother machine, that machine will have the errors occur on drawings that previously had no issues on that machine.  In other words, it appears that it's now "infected".  In this way, it does sound like a virus or corruption of some some sort.

I've taken large chunks of our customization out and have yet to find any pattern as to when the error will or will not occur - only opening straight AutoCAD solves the problem.

I'm getting to the point where I just want to diable EATTEDIT and tell everyone just to use Quick Properties for editing.  But then worry that this is just the tip of an iceberg.

Has anyone ever encountered this?

Where actually is the definition for EATTEDIT held?

[pendean]

>>>...  When a drawing that has this problem is opened in an Autodesk session with the out-of-the-box Unnamed Profile, all is fine...<<<

So when the drawing is in a custom profile it crashes?

>>>... if a machine that has had no issues opens a drawing...<<<

If Windows or AutoCAD is restarted, does the no-problem machine stop having problems with files other than the 'broken' one?

Does anyone try to fix these files? Using what method?

Can you post a 'problem' file?

[Anonymous]

>>>...  When a drawing that has this problem is opened in an Autodesk session with the out-of-the-box Unnamed Profile, all is fine...<<<

So when the drawing is in a custom profile it crashes? YES, and I now think the culprit is VBA (see below).

>>>... if a machine that has had no issues opens a drawing...<<<

If Windows or AutoCAD is restarted, does the no-problem machine stop having problems with files other than the 'broken' one? NO, the problem starts to occur every time EATTEDIT is used.

Does anyone try to fix these files? Using what method?  We've thought that recovering the drawing and its xrefs works but the problem shows up again later.  It's occurance is so erratic that we can't hold enough variables constant.

Can you post a 'problem' file?

[pendean]

Thank you for the detailed update of your findings.