Jump to content
Developer Wiki and Function Reference Links ×

VW2021: SDK projects crash on runtime Debug, but not on Release


Nebeor

Recommended Posts

Hello everybody,

I am planning to migrate my plugins to Vectorworks 2021

However, when I try to run on debug, the loading screen of Vectorworks halts on the SDK code

somewhere down in the destructor of the TXString. (this happens with my own code, just as with the sample project).

image.thumb.png.878ee9a6fba647070d418835132ebba7.png

I can see this is due to the _ITERATOR_DEBUG_LEVEL, I think it tries to warn me about something,  but I don't see how this connects with my code...because I don't see any in my stacktrace.

Iterating over the code with a breakpoint didn't helped me either... It crashed after exiting ModuleMain...

 

When I build with Release: most of the things works, but in order to fix the things that are broken, I need the debugger.

I am looking forward to your answers!

 

Link to comment
  • 2 weeks later...

Thank you for you reply,

Does this mean that the workaround on http://developer.vectorworks.net/index.php/SDK:Debugging_SDK_Plugins will eventually work?

If not, I don't see the point of this tutorial.

I just want to be able to use breakpoints and watches, nothing fancy like "Edit and Continue" which i've never used with Vectorworks before.

Right now, I managed to make a copy from the "release" config work as "debug", but i am still not able to connect with the debugger.

Link to comment
  • 2 months later...

In order to connect a debugger to a Release build under MSVC there are two important settings for building your plugin:

  • C/C++ > General > "Debug Information Format: Program Database (/Zi)" (C7 compatible also works, but is larger)
  • Linker > Debugging > "Generate Debug Info: Generate Debug Information (/DEBUG)"

The "PDB" file this generates is your key to debugging, keep each version safe as you will need the correct one to debug each individual build.

By default they'll be alongside your VW plugin, with the extension "PDB".

(There is ident information inside each PDB so windbg and visual studio know which is right. Google MSVC Symbol Server for nice ways to store multiple versions)

 

You do not need to disable optimisations, however doing so can make single-stepping more predictable - clearly you can't step into code that has been optimised away!

 

However, any stack backtraces that enter Vectorworks code not covered by the PDBs in the SDK (eg walking your callstack backwards from a breakpoint or from crashes in the field) are likely to be very wrong as x64 stackwalking requires PDB information. (This wasn't true of MSVC x86 code)

 

Vectorworks don't appear to have published PDBs for the main application, which is a shame.
It would be nice if they would do so - though it would have to be a "stripped" version of course so as not to expose any of their private proprietary information.

Edited by Richard1
Link to comment
  • 7 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...