2015 Crashes Trying to Customise Quick Properties

[jason.teagle]

Windows 7 64-bit. Multiple versions of AutoCAD. 

When one of our custom objects is selected and we try to invoke the CUI command (for example, when no quick properties are currently defined and you click the offered link to add some), AutoCAD is taking exception to something in our code, and I'm trying to figure out what. 

Under 2012 SP1, built in full Release, we get the .NET unhandled exception dialog. If you click Continue, it will do so but without our objects. 

Under 2015 SP2, run in Debug, it gives a C++ exception as shown below: 

As you can see, the last place in the call stack was acdb20.dll, but due to the ongoing problem of not being able to load symbols for certain DLLs (I'm still trying to get that resolved with AutoDesk via a partner centre support request), I can't see what it tried to do last. If I could, I might be able to guess where to look next. 

I suspect the problem is in our COM wrapper classes, which are certainly accessed during the CUI operation. 

I've tried putting breakpoints in various methods we override (the standard ones for providing information to the system about our properties, and for manipulating objects in general such as forceDbResident() ), but it always seems to get past our code. That doesn't mean it isn't us though. I *do* know it appears to use a null object ID for the wrapper, but as far as I can tell we've handled that gracefully. 

Anyone got any suggestions as to where in the wrapper to look, or had a similar problem? 

[owenwengerd]

Symbols normally don't help unless you're debugging Autodesk's code. Set VS to break on the exception and inspect the call stack at that point. Ignore Autodesk's modules and trace back to your code.

[jason.teagle]

Unfortunately, that's the problem - the crash isn't happening during our code at all. It's all on the AutoCAD side, during the CUI command (which never gets to commandEnded(), I note, but *does* get past commandWillStart() and also gets cleanly through our overrides of beginDeepClone(), beginDeepCloneXlation() and endDeepClone() - although what causes the cloning I don't know). Here's a stack trace: 

I admit that getting the symbols for the AutoCAD side is a long shot but it's the best I've got. I can only assume we're supplying some bad data somewhere (or leaving some data it is expecting uninitialised), which then causes this problem later (which is why I thought knowing what it was looking at at the point of death might give me a clue as to what we supplied incorrectly or missed supplying).

Without knowing what that data might be, I'm stuck. Throughout the day I've tried looking at various places in the wrapper class (and our cloning overrides as mentioned above) that it might be calling to see if we're doing something naughty but the cloning code is passed without a hitch and even when it calls the wrapper with a null object ID, we cope gracefully (by returning an HRESULT other than S_OK). It simply isn't practical to go and change all instances to temporarily return S_OK in case that is the issue, but it shouldn't be necessary because it is only our wrapper get_XXX() and put_XXX() methods that handle it like this - and it shouldn't even be calling those for just getting the propery descriptions for the CUI dialog (I tried a breakpoint in one such method, but it never got there during CUI, as expected). 

AutoCAD 2013 is a similar story, so at least this one isn't unique to 2015. And I can't load symbols for acdb19.dll in that either. 

[jason.teagle]

Just to clarify, selecting our objects and viewing the properties in the normal (full) palette have no problems whatsoever.

[owenwengerd]

I can't tell from your screen shot; which modules contain the code preceding the function that triggered the exception? Are they native or managed modules?

You can go to Options/Debugging/General and enable "Load dll exports" to see exported symbols for acdb20.dll.

[jason.teagle · Accepted solution]

I don't know what the modules are either; what you see is what I saw, unnamed ones. Normally it never has a problem naming the source library. That System.Windows.Forms.ni was the last module shown. I would suggest they are managed code, but then it showed the Forms DLL without issues. 

However, I am pleased to report that I thought of another way to approach the debugging problem and have discovered the cause of the problem. I'll show it here in case it helps someone trying to track down a similar problem: 

When CUI is building the entries for custom objects, it calls methods in our COM wrapper classes with m_objId set to a null value, as opposed to a valid ID of such an object when you select that object and it is showing the full properties. It doesn't need a real object; it's only trying to get the labelling information for properties (and possibly type information). 

In a COM wrapper class, if you use a standard smart pointer (or acdbOpenObject() ) and m_objId, under these circumstances it will fail (due to the null ID), and since we should be checking openStatus() or the result of acdbOpenObject(), we move gracefully past that problem. 

With AcAxObjectRefPtr, however, when m_objId is null, it creates a dummy object that appears to be perfectly valid, to make the calls on that. This seems to be perfectly acceptable - but that was the cause. Once I used m_objId instead and let it silently fail and move on, the crash went away. 

(Although it doesn't call any get_XXX() methods which normally access the object, we do some object access during GetDisplayName() so that we can return some alternative strings depending on certain properties. For example, the object might represent a generic component, and we return "Timber" or "Steel" for the main object description depending on certain flags. This was where the offending AcAxObjectRefPtr was used). 

[owenwengerd]

---

@jason.teagle wrote:

I don't know what the modules are either; what you see is what I saw, unnamed ones. Normally it never has a problem naming the source library. That System.Windows.Forms.ni was the last module shown. I would suggest they are managed code, but then it showed the Forms DLL without issues. 

---

I guess those functions were dynamically generated managed code that was compiled at runtime. You had the 'Language' column hidden in your screen shot, but that would have been a clue. In any case, I'm glad you got it resolved.