Debug Assertion Failed! Expression: __acrt_first_block == header

debug assertion __acrt_first_block == header
debug_heap cpp line: 996
c++ error acrt_first_block header
minkernelcrtsucrtsrcappcrtheapdebug_heap cpp
expression result pp_ok
minkernel crts ucrt src appcrt heap debug_heap.cpp line 904

I am trying to test the dll which I wrote with GoogleTest and when I call one of the tests It throws me this error:

I have come to the conclusion that the problem is in assigning memory to vectors but I don't know how to resolve this as I am fairly new to C++ programming. The code is as follows:

#define ARRAYSCP11_API __declspec(dllexport)
#define ARRAYSCP11_API __declspec(dllimport)

__declspec(dllexport) void removeWhiteSpaces(std::vector<std::string> v, std::vector<std::string> &output);
void removeWhiteSpaces(std::vector<std::string> v, std::vector<std::string> &output) { //odstranjevanje presledkov iz vector-ja (vsak drugi element je bil presledek)
    for (std::vector<std::string>::iterator it = v.begin(); it != v.end(); it++) {
        std::string buffer = *it;
        if (isdigit(buffer[0])){;

template<class T> 
class TestTemp
   void SetValue(T obj_i);
   T GetValue();
   bool alwaysTrue();
   bool TestTemp<T>::formattingTest(std::string input, std::vector<std::string> realVector, std::vector<std::string> formattedInput);
   T m_Obj;

template<class T>
inline bool TestTemp<T>::formattingTest(std::string input, std::vector<std::string> realVector, std::vector<std::string> formattedVector) {
std::string input2 = input;
//  std::vector<std::string> fResult;
std::string first;
std::string second;
bool endResult = true;
std::vector<std::string> end;
//std::vector<std::string> result = split(input2, ' ');
std::vector<std::string>::iterator yt = realVector.begin();
for (std::vector<std::string>::iterator it = end.begin(); it != end.end(); it++, yt++) {
    first = *it;
    second = *yt;
    if ( != 0) {
        endResult = false;
return endResult;
struct formattingTesting{
   //   formattingTesting* test;
   std::string start;
   std::vector<std::string> endResult;
   formattingTesting() {
   explicit formattingTesting(const std::string start, const std::vector<std::string> endResult)
    : start{start}, endResult{endResult} 

struct fTest : testing::Test {
   formattingTesting* test;
   fTest() {
      test = new formattingTesting;
   ~fTest() {
      delete test;

struct format {
   std::string start;
   std::vector<std::string> end;

struct formTest : fTest, testing::WithParamInterface<format> {
   formTest() {
      test->start = GetParam().start;
      test->endResult = GetParam().end;

TEST_P(formTest, test1) {
   bool endResult = true;
   TestTemp<int> TempObj;
   std::string first;
   std::string second;
   //std::string start ("1  2 3 4 5 6 7 8 9 10");
   //std::vector<std::string> end = { "1","2","3","4","5","6","7","8","9","10" };
   std::vector<std::string> start2 = { "1","","2","3","4","5","6","7","8","9","10" };
   std::string start = GetParam().start;
   std::vector<std::string> end = GetParam().end;
   bool result = TempObj.formattingTest(start,end,start2);      

INSTANTIATE_TEST_CASE_P(Default, formTest, testing::Values(
   format{ "1", {"1"} },
   format{ " ", {} },
   format{ "1 2 3 4 5",{"1","2","3","4","5"} },
   format{ "1  2 3 4 5  6", {"1","2","3","4","5","6"} }

int main(int argc, char** argv)
   testing::InitGoogleTest(&argc, argv);
   return 0;

As this is a DLL, the problem might lie in different heaps used for allocation and deallocation (try to build the library statically and check if that will work).

The problem is, that DLLs and templates do not agree together very well. In general, depending on the linkage of the MSVC runtime, it might be problem if the memory is allocated in the executable and deallocated in the DLL and vice versa (because they might have different heaps). And that can happen with templates very easily, for example: you push_back() to the vector inside the removeWhiteSpaces() in the DLL, so the vector memory is allocated inside the DLL. Then you use the output vector in the executable and once it gets out of scope, it is deallocated, but inside the executable whose heap doesn't know anything about the heap it has been allocated from. Bang, you're dead.

This can be worked-around if both DLL and the executable use the same heap. To ensure this, both the DLL and the executable must use the dynamic MSVC runtime - so make sure, that both link to the runtime dynamically, not statically. In particular, the exe should be compiled and linked with /MD[d] and the library with /LD[d] or /MD[d] as well, neither one with /MT[d]. Note that afterwards the computer which will be running the app will need the MSVC runtime library to run (for example, by installing "Visual C++ Redistributable" for the particular MSVC version).

You could get that work even with /MT, but that is more difficult - you would need to provide some interface which will allow the objects allocated in the DLL to be deallocated there as well. For example something like:

__declspec(dllexport) void deallocVector(std::vector<std::string> &x);

void deallocVector(std::vector<std::string> &x) {
    std::vector<std::string> tmp;

(however this does not work very well in all cases, as this needs to be called explicitly so it will not be called e.g. in case of exception - to solve this properly, you would need to provide some interface from the DLL, which will cover the vector under the hood and will take care about the proper RAII)

EDIT: the final solution was actually was to have all of the projects (the exe, dll and the entire googleTest project) built in Multi-threaded Debug DLL (/MDd) (the GoogleTest projects are built in Multi-threaded debug(/MTd) by default)

MSVC with /MT: Debug Assertion Failed! __acrt_first_block , MSVC with /MT: Debug Assertion Failed! __acrt_first_block == header #209 /​MTd for debug configurations), any sort of call to RTTRs API causes a debug assertion fail: Line: 996 Expression: __acrt_first_block == header. Building google test 1.8.1 in a debug shared object and running tests results in debug assertions from the VC++ runtime. The code in question was compiled with VS 2015 with all the latest updates applied. The call stack shows this to be

I had a similar problem and it turned out that my unittest project was set to a different code generation runtime library - so by setting it to the same as the DLL project, then no heap exception

Debug Assertion Failed! Expression: __acrt_first_block , Debug Assertion Failed! Expression: __acrt_first_block == header #88. Closed. wguo68 opened this issue on Dec 29, 2016 · 6 comments. Closed  It's hard to help without more details. Can you run the INSTALL target and run from the install-dir, to make sure all paths are correct? Also check this in the debugger, and then check the variables before returning - i.e. did the function get all the correct arguments and do something "useful" with it? Could it be you're running out of memory?

I was seeing this error too and in my case I had all the memory model settings lined up correctly. However having recently upgraded the projects from vs2013 to vs2015 I had stale references between the .exe and .dll, so in fact I was using the old DLL built with 2013. I had to remove the reference between the .exe and .dll and re-add it to update the name of the .lib that the exe was linking against. (Right click on the "References" child item of the .exe project and "Add", while confusingly also allows you to remove a reference).

Crash: Expression: __acrt_first_block == header in xstring , Crash: Expression: __acrt_first_block == header in xstring Upon calling the return statement, I get a debug assertion failed crash with the message mentioned  It crashes with a debug assertion: __acrt_first_block == header on the last line (return MatlabImage). Tracing back the source of the assertion, it seems to be connected to deallocating the vector ColorChannels.

That verification was implemented by Microsoft software developers a long time ago in 1992 - 1993 and it is No Longer valid since in case of Heterogeneous or MPI programming a new memory Could Be allocated Not from a Local Heap.

When an application gets a memory using OpenCL or CUDA APIs a GPU driver does all memory allocations and, of course, it doesn't use the Local Heap of the application. However, the application should release the memory before it exits. At that time Microsoft's Memory Leaks Detection API detects it and that assert is displayed.

Please take a look at a Video Technical Report regarding origins of that verification:

Origins of MS Visual Studio 2015 Assert __acrt_first_block == header ( VTR-010 )

Note: A weblink to the youtube video updated since I've uploaded a video with some corrections.

QuantLib / [Quantlib-users] Debug Assertion Failed message, Debug Assertion Failed! Expression: __acrt_first_block == header · c++ visual-​studio-2015 asked Feb 10 '16 at 8:29. Top Answers. Upon calling the return statement, I get a debug assertion failed crash with the message mentioned in the title of this post. The program seems to break in the basic_string destructor found in xstring: ~basic_string() _NOEXCEPT { // destroy the string _Tidy_deallocate(); }

On how to loose half day - aiaf's Blog, Program: uvm.exe File: minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp Line: 996 Expression: __acrt_first_block == header For information  For debug builds some compilers add padding or safety memory around objects in memory which is never to be touched. If this padding memory is altered at runtime, the program "knows" that something bad happened and throws an exception like the one you saw.

C++ has an exception ". \debug_heap.cpp Line:980 Expression , I had a window popping up every time i was closing the game.Error below: Debug Assertion Failed! Expression: __acrt_first_block == header. Hi Nick, You say "Where I convert date1 (and date1_format) from a QString to a std::string my code blows up" - so the line which blows up involve a class from Qt, and a class from the C++ standard library, right?

Visual Studio 2015 Oracle exception debu, Expression: __acrt_first_block == header failure, see the Visual C++ documentation on asserts. Assertion failed (mtype == type0 || (CV_MAT_CN(​mtype) And _CrtIsValidHeapPointer() in DEBug mode will ensure that the incoming 

  • You have undefined behavior in your code. You have an empty string in the start2 vector, that you ultimately pass to the removeWhiteSpace function, where you access the first character of the strings in the vector. If a string is empty, it doesn't have a first character, so you are indexing out of bounds. Also the name removeWhiteSpace is not very good, as the function doesn't actually remove white-space, it just checks if the first character of a string is a digit or not (wrongly as I just noted).
  • @JoachimPilebog the vector start2 is primarily used for debugging the comparison part of the test (the part of the code that's after the call of removeWhiteSpaces) and will be removed after I fix the issue. Also the function removeWhiteSpaces does actually remove the white-space as it pushes only the elements that are digits into a new vector
  • Btw. why do you copy the vectors all over instead of passing them by const reference (for example in removeWhiteSpaces(std::vector<std::string> v, ...) where you only look at the vector v so it doesn't need to be non-const).
  • @axalis Well to comment on your example from what I understand (I am very much a complete beginner in C++) I made the function work so the vector v is an input and the function pushes the values that are digits into the vector output. I do know that there's probably a better way to deal with that but I haven't really found one so any advice would be greatly appreciated
  • The point is you can use void removeWhiteSpaces(const std::vector<std::string> & v, std::vector<std::string> &output); to not copy the first vector (and use std::vector<std::string>::const_iterator instead of std::vector<std::string>::iterator inside). Similar for some other functions with input parameters which do not need to be modified inside.
  • I am going to try that but sadly in the end I need to find a way to make it work as a DLL as my supervisor wants it like that
  • Updated the answer, you basically need to link against the dynamic runtime to avoid this kind of problems.
  • so if i'm understanding correctly I need to set the runtime library of the exe to /MD and the one of DLL to /LD right? If so, I can't really do that for the DLL because the /LD option is not given to me
  • Hum ... I think you can use /MD for the library as well, the /LD just provides some additional automatic macro definitions AFAIK (maybe it was removed in the newer versions, I don't see it in MSVC 2013 either)
  • Well building the exe in /MD results in me getting a bunch of linker errors (I have been building it in /MT until now and it was bullt correctly)