Revit crashes in CDialog::DoModal()

[Anonymous]

Hello everybody,

I'm developing an external application for Revit 2013/2014 and everytime I'm trying to popup an mfc dialog modally in release mode Revit crashes.

Here's my solution in detail:

0. I'm using Visual Studio 2010 SP1 for all my coding

1. project (c#) is an external application being loaded on Revit startup

2. project (c++/cli) is a mixed mode dll being referenced by the c# project

3. project (native c++) is a dll getting loaded (via LoadLibrary) displaying mfc dialogs or just doing the hard work

Here's the problem in detail:

- I start an external command which eventually calls into native c++ and displays an mfc dialog by DoModal()

- If I compile my code in debug mode everything works like intended

- If I compile my code in release mode, Revit crashes in CDialog:: DoModal() as soon as my overloaded OnInitDialog method finishes

I'm aware that I can debug release builds and I have already done so. After all I don't think my code is wrong, because

a) everything is fine in debug mode and if I start up the dialog outside of an external command (like after my application has finischede loading), the dialog is displayed without a crash in both debug and release mode and

b) program execution has left my dialog code when Revit crashes (after my OnInitDialog).

I also tryed using BoundsChecker to see whether something is fishy, but I'm still tinkering with it.

Is that what I'm trying to do actually intended to work or am I just missing something utterly obvious?

I'd really appreciate it if someone could point me in the right direction to sort this out.

Thanks in advance,

Kornel

ps: Here's my callstack at crash time if that helps:

=>RevitMFC.dll!00000000137b7c26()  
---8<--- these frames could be incorrect...
  APIUI.dll!0000000011e81179()  
  APIUI.dll!0000000011e814a7()  
  RevitAPIUILink.dll!00000000382f20b3()  
  DesktopMFC.dll!00000000008016bf()  
  000007fe8eb3d9e3() 
  000007fe8eb3d429() 
  000007fe8eb3d31c() 
  000007fe8d07a2cc() 
  000007fe8d07980b() 
  000007fe8d079665() 
  000007fe8d07941b() 
  000007fe8d0790ea() 
  000007fe8d078ee6() 
  000007fe8d078676() 
  000007fe8d07524a() 
  000007fe8d074da4() 
  000007fe8d0747f5() 
  000007fe8e8ce999() 
  000007fe8cfc8536() 
  000007fe8cedb713() 
  000007fe8cedb580() 
  000007fe8e8ce8cb() 
  000007fe8c6f06f5() 
  000007fe8c6f0507() 
  000007fe8e8c576c() 
  000007fe8e8c4da5() 
  000007fe8e8c4209() 
  000007fe8e8c413f() 
  000007fe8e8c3fb3() 
  000007fe8e8c3cb8() 
  000007fe8e8c3855() 
  000007fe8c6f09ae() 
  000007fe8c6f087c() 
  000007fe8c6f06f5() 
  000007fe8c6f0507() 
  000007fe8c6efee7() 
  000007fe8c6ecd2e() 
  000007fe8c6ec383() 

--->8---
  clr.dll!UMThunkStub()  + 0x6e Bytes 
  user32.dll!UserCallWinProcCheckWow()  + 0x11d Bytes 
  user32.dll!DispatchMessageWorker()  + 0x12a Bytes 
  mfc100u.dll!AfxInternalPumpMessage()  + 0x52 Bytes 
  mfc100u.dll!CWnd::RunModalLoop()  + 0x10f Bytes 
  mfc100u.dll!CDialog:: DoModal()  + 0x1dd Bytes 
> PitGui.dll!CPitTestDialog:: DoModal()  Zeile 36 + 0xd Bytes C++

[augusto.goncalves]

HI,

So one more thing that might help us investigate: when the crash happens, can you send the report with your email on it? That way we can track it here...

Thanks!

[Anonymous]

It's been years since I've done native c++ and I never really touched MFC (Win32 was all I needed), but I remember that in vc++ the debug config had a compiler switch that would help out by initialising pointers to null when allocated, while release mode would not, leaving them as junk unless specifically set to null.

Bugs that only showed up in release mode were commonly caused by passing uninitialised pointers to code that treated a null pointer as a switch to leave it alone, while fully trusting any non-null pointer and having its way with it. As an isolation test, try building everything in release mode except for the native c++ dll, then link with the debug version of the c++/MFC code and see it still crashes.

You say that everything works fine if you open the same dialog later after the main app is finished loading. There might be a pointer that is left uninitialised until some other part of the startup code completes and is then set to some meaningful value.

Sorry if this is all obvious information and you've already ruled this out, never hurts to try lending a hand though.