Windows 8.1项目的Windows 10 Visual Studio 2013生成错误

Question

Im getting an error when building a win8.1 project on Windows 10 using VS2013

'RAIG3D.Windows.exe' (Win32): Loaded 'C:\Windows\SysWOW64\mswsock.dll'. Symbols loaded.
Debug Assertion Failed!

Program: ...win8.1-universal\Debug\RAIG3D.Windows\AppX\RAIG3D.Windows.exe
File: f:\dd\vctools\crt\crtw32\misc\dbgheap.c
Line: 1424

Expression: _pFirstBlock == pHead

Im using winsock2.h in a .dll thats linked to the project. Its a custom network library im trying to write. Its on the windows branch

https://github.com/damorton/libsocket/tree/windows

This library works for win32 debug programs fine, but for win8.1 its giving the above error

Answer 1

This is not a build error, it's a run-time error. Specifically, an assertion has fired. This is what the message is telling you:

Debug Assertion Failed!

A piece of code has just executed that uses some variant of an assert macro to catch possible bugs. It caught one. Which is nice. Even better, it tells you where that assert macro was fired:

Program: ...win8.1-universal\\Debug\\RAIG3D.Windows\\AppX\\RAIG3D.Windows.exe
File: f:\\dd\\vctools\\crt\\crtw32\\misc\\dbgheap.c
Line: 1424

That's your program, but not your code file. So it isn't an assertion that you wrote, it's one that the Microsoft developers put in their C run-time library routines. Specifically, in the dbgheap.c file, which suggests that it has something to do with the debug heap, which is used to allocate memory in debugging builds.

The message also tells you what the expression was that turned out to be unexpectedly false and therefore triggered the assert:

Expression: _pFirstBlock == pHead

Looks like two pointers that were supposed to be equal were actually not equal.

If you had pressed the "Retry" button on the message box that popped up, you would have been able to break into the code with the debugger and see the offending line of code in context. You also would have had a full call stack to look at.

The call stack would have been helpful to see which line of your code was executing before you called into library code that fired this assertion. This assertion is an internal consistency check that the CRT authors put in their memory allocation routines. If you're triggering it, you're doing something badly wrong inside of your application.

If I were to hazard a guess, without having any more information available to me than I do, I'd guess that you were probably trying to mix executables and libraries that reference different versions of the CRT. This is unsupported and likely to result in serious problems. Different versions of the CRT have different object sizes, memory layouts, static variables, etc. You're lucky this time it was caught by an assertion. Check that all of your projects are targeting the same version of the CRT, including the ones that generate DLLs and LIBs. Do a full rebuild from scratch to ensure that they've all been updated.