Drawing Recovery issue

1
Chris Smith
10/11/2021 11:48 PM

Hi Wout,

After updating to version 4.0.39.6 we're getting a "The drawing file requires recovery" issue opening the drawing in AutoCAD 2020. Console shows:

Code:
Class dictionary  AcDbVisualStyle id 514 already in use Ignored
Class dictionary           id 500 Unexpectedly unused   Filled with dummy
Validating objects in the handle table.
Valid objects 14646  Invalid objects 0
Validating objects completed.
    Salvaged database from drawing.
Auditing Header
Auditing Tables
Auditing Entities Pass 1
Pass 1 14600   objects audited
Auditing Entities Pass 2
Pass 2 14600   objects audited
Auditing Blocks
 17      Blocks audited
Auditing AcDsRecords
Total errors found 0 fixed 0
Erased 0 objects
Opening an AutoCAD 2010/LT 2010 format file.
Regenerating model.
AutoCAD menu utilities loaded.*Cancel*
Command:

I'll see if I can generate a sufficiently low value DWG that I can attach it here - but seems to happen for any drawing written by CadLib.

We're not doing anything complex re saving the DWG, just:

C# Code:
DwgWriter.Write(ms, context.DxfModel);

Cheers,
Chris

Chris Smith
10/12/2021 11:18 PM

Hi Wout,

Looks like I was a bit hasty on the "any drawing written" part. It seems to be some kind of issue with Cadlib opening the template that we're using. Any drawing that's saved after having started with the template is broken. Other drawings starting with other templates are fine.

Just saving an empty drawing based on the template is enough to end up with something broken:

C# Code:
var dwt = DwgReader.Read("bad.dwt");
var dxf = new DxfModel(dwt);
DwgWriter.Write(@"C:\temp\test.dwg", dxf);

I've attached the template that causes the issue.

Not sure if it helps but we had sent the bad drawing to BricsCAD wondering if it was just a Brics issue and they suggested that the dimension leader styles seemed to be broken ("partially upgraded" from 2010 format or something - some missing XDATA they suggested).

Anyway - let me know if there's anything else we can do to help.

Cheers,
Chris

Chris Smith
10/12/2021 11:36 PM

Some more info that was passed on to us - I'm assuming I'm allowed to post this 🙂

For background - the original template was in 2010 format, the one I've uploaded here is in 2018 format after using AutoCAD to upgrade it - still causes the issue.


OdDbMLeaderStyle filer stream has an "old format" and a "new format" (that contains two additional values). MLeaders were introduced in AutoCAD 2008. Apparently the "old format" was written by early versions of AutoCAD 2008, but at some point AutoCAD started writing in "new format". To distinguish new format from old, a version number is added in xdata when writing in new format. In the attached drawing, the mleader style is actually filed in new format, but there is no xdata attached so it is expected as old format.

As I can see, while opening the original drawing with Notepad, that is: AC1018, so AutoCAD 2004 format. I guess the drawing was created using a 17 years old .dwt template. If that is the case, perhaps using a newer template could help.

If I open the drawing with AutoCAD 2020, that contains only the "Standard" MLeaderStyle, handle "3BBCF1". Then run AUDIT, AutoCAD fixes two AcDbTableStyles handle "1E" and "33" (attached).
AutoCAD does not recreate internally the "Standard" MLeaderStyle, handle "3BBCF1" remains in the drawing.

Cheers,
Chris

Wout
10/13/2021 9:03 AM

Hi,

I released a new CadLib 4.0 version with a fix (haven't updated the .net standard version yet).

As far as I can see the problem was a duplicate visual style class created during cloning.

I didn't seen a problem with the mleader style, nor did I see any xdata in the mleader style object in the drawing you attached.

- Wout

Chris Smith
10/13/2021 10:29 PM

Thanks Wout!

Sadly looks like I'm still waiting on our purchasing department to renew our support agreement so I can't test it 😟

1