4

I am developing a Windows Forms application under Visual Studio 2015. It was migrated from code running under VS2008.

When I try to launch the Debug version of the application, I get the message box below, before anything appears. I have also copied the call stack.

None of my code is called, the crash occurs before, during application initialization. It seems to be a heap corruption.

I have tried many things, such as reinstalling VS with different options, changing the Target Platform Version, switching between 32 and 64 bits. Nothing worked.

Is this a known issue ? How can I address this ?

I somewhat suspect a problem with ucrtbased.dll, as I found several posts about installation problems of this dll with VS2015.

enter image description here

ucrtbased.dll!_msize_dbg(void * block, int block_use) Line 1059 C++
ucrtbased.dll!_recalloc_dbg(void * block, unsigned __int64 count, unsigned __int64 element_size, int block_use, const char * file_name, int line_number) Line 784   C++
ucrtbased.dll!_register_onexit_function::__l2::<lambda>() Line 112  C++
ucrtbased.dll!__crt_seh_guarded_call<int>::operator()<void <lambda>(void),int <lambda>(void) & __ptr64,void <lambda>(void) >(__acrt_lock_and_call::__l2::void <lambda>(void) && setup, _register_onexit_function::__l2::int <lambda>(void) & action, __acrt_lock_and_call::__l2::void <lambda>(void) && cleanup) Line 204   C++
ucrtbased.dll!__acrt_lock_and_call<int <lambda>(void) >(const __acrt_lock_id lock_id, _register_onexit_function::__l2::int <lambda>(void) && action) Line 961   C++
ucrtbased.dll!_register_onexit_function(_onexit_table_t * table, int(*)() function) Line 149    C++
mViz Comparator.exe!_onexit(int(*)() function) Line 268 C++
mViz Comparator.exe!atexit(void(*)() function) Line 276 C++
mViz Comparator.exe!__scrt_initialize_thread_safe_statics() Line 109    C++
00007ff889c217db()  Unknown
00007ff889c2170f()  Unknown
00007ff889c214be()  Unknown
00007ff889c2105e()  Unknown
00007ff889c20dc3()  Unknown
00007ff889c209c3()  Unknown
clr.dll!CallDescrWorkerInternal()   Unknown
clr.dll!CallDescrWorkerWithHandler()    Unknown
clr.dll!DispatchCallDebuggerWrapper(struct CallDescrData *,class ContextTransitionFrame *,int)  Unknown
clr.dll!DispatchCallSimple()    Unknown
clr.dll!MethodTable::RunClassInitEx()   Unknown
clr.dll!MethodTable::DoRunClassInitThrowing()   Unknown
clr.dll!MethodTable::CheckRunClassInitThrowing()    Unknown
clr.dll!DomainFile::Activate()  Unknown
clr.dll!DomainFile::DoIncrementalLoad() Unknown
clr.dll!AppDomain::TryIncrementalLoad() Unknown
clr.dll!AppDomain::LoadDomainFile() Unknown
clr.dll!AppDomain::LoadDomainAssemblyInternal() Unknown
clr.dll!AppDomain::LoadDomainAssembly() Unknown
clr.dll!AppDomain::LoadAssembly(class AssemblySpec *,class PEAssembly *,enum FileLoadLevel,struct AssemblyLoadSecurity *)   Unknown
clr.dll!SystemDomain::ExecuteMainMethod()   Unknown
clr.dll!ExecuteEXE(struct HINSTANCE__ *)    Unknown
clr.dll!_CorExeMainInternal()   Unknown
clr.dll!_CorExeMain()   Unknown
mscoreei.dll!_CorExeMain()  Unknown
mscoree.dll!_CorExeMain_Exported()  Unknown
kernel32.dll!BaseThreadInitThunk()  Unknown
>   ntdll.dll!RtlUserThreadStart()  Unknown

Update:

The problem persist with other similar applications and also 32/64 Release/Debug builds.

But I have now observed that the problem is due to a global instance of a class defined in a separate unmanaged library. Note that this code has been working for ages with many Visual Studio versions. Also note that the crash occurs before the constructor is called.

  • If you create a new empty project with target of WinForm run fine? – Kevin Kouketsu Sep 10 '19 at 20:01
  • Possible duplicate of https://stackoverflow.com/questions/35575805/afxwin-h-issues-in-visual-studio-2015-windows-form-app – Alex Broadwin Sep 10 '19 at 20:08
  • @KevinKouketsu: yes, I have other programs made in the same conditions that work correctly. See the updated update. –  Sep 10 '19 at 20:13
  • The Winforms project templates were removed at VS2012. Astonishing how quickly it went down-hill after that. The CRT rewrite at VS2015 caused nasty SIOF problems that look like this. Check [this post](https://stackoverflow.com/a/15190400/17034). – Hans Passant Sep 10 '19 at 20:14
  • @HansPassant: much to my relief, we have it ! This indeed seems to be a SIOF problem and the workaround suggested in the post works (set the EntryPoint to ?mainCRTStartupStrArray@@$$FYMHP$01EAPE$AAVString@System@@@Z). If you post, the bounty is yours. –  Sep 10 '19 at 20:22
  • @AlexBroadwin: yes, the two cases are related. In my case the fix is different as I am not using MFC. Thanks. –  Sep 10 '19 at 20:24
  • Would it be possible to post an [\[SO\]: How to create a Minimal, Reproducible Example (reprex (mcve))](https://stackoverflow.com/help/mcve)? Where is that global instance initialized/used? – CristiFati Sep 11 '19 at 12:58
  • @CristiFati: no, the code involved is huge and I have the solution (this is a known issue with VS2015). Just waiting for HansPassant to post. –  Sep 11 '19 at 13:54
  • 1
    AAAh, *OK* (didn't carefully read all the comments). I was thinking about static initialization order. – CristiFati Sep 11 '19 at 15:36
  • Please try to check this option: https://stackoverflow.com/questions/32914250/c-cli-dll-crashes-on-load-after-port-to-vs2015-net-4-6/35363914#35363914 – alexb Sep 15 '19 at 00:04
  • @HansPassant If you post your comment, the bounty is yours. –  Sep 16 '19 at 20:09
  • I can't reasonably duplicate answers, not the SO way. Do feel free to vote as a dup yourself, quicker that anybody else doing it. – Hans Passant Sep 16 '19 at 21:52
  • @HansPassant: what for ? I can't bounty myself. Sorry for the disturbance. –  Sep 17 '19 at 07:45
  • @YvesDaoust It looks like a mismatch between 32bit vs 64bit versions. I see you did some switching between the versions but if you have a mismatch in both versions you'll still get an error (64bit version finds a 32bit dll/lib, while 32bit version alternatively finds a 64bit dll/lib for some other dependency). I advise commenting out portions of your code and/or removing dependencies to figure out where exactly lies the problem. In any case, 2015 is kinda old already isn't it? – ALX23z Sep 17 '19 at 08:24
  • 1
    @ALX23z: the question is solved. It was a SIOF problem due to a known bug in VS 2015. The Update tells you that I did find where the problem exactly lied. The age of VS doesn't matter, I have to support down to 2008. –  Sep 17 '19 at 08:35
  • @YvesDaoust This is very unfortunate that you have to support down to 2008. Better to make a fixed static branch for old versions and move forward with development to newer versions even if it means that the newer versions won't support old systems/configurations. Microsoft, doesn't support too well older versions of VS, in our company we have to use a specific version of VS 2017 because in newer versions there is a crucial bug which will never be fixed in VS 2017 because Microsoft moved on to VS 2019 (that bug was indeed fixed in VS 2019 tho). – ALX23z Sep 17 '19 at 08:45
  • @ALX23z: I do like VS2008, it is very fast and quite stable. Migration to more "modern" versions always comes with its load of incompatibilities, bugs and other goodies, for little benefit. I don't think I'll see more requests for Visual Studio 6.0 (last time was around 2014 I guess). –  Sep 17 '19 at 09:15

0 Answers0