Access violation reading location before entering main - c++

Question

After upgrading from Visual Studio 2012 to Visual Studio 2015 my project gets heap corruption and access violation errors before even reaching the main function. There is simply no code that I can debug. I checked for static variables and anything that can possibly be created on a stack but I do not seem to have any. I tried to launch the program with empty main function:
int main(){return 0;};
but I still get access violation error. The program is a GUI form with mixed C++/CLI code. I made sure I have rebuilt third party libraries (curl) from source with VS2015 and use correct DLLs. Have no clue where do these errors come from - everything worked fine before. How can I fix/debug it? I googled a lot and tried even running gflags but the debugger does not stop on any human readable code. The error reads:
Exception thrown at 0x5A4C7988 (verifier.dll) in MyProgramName.exe: 0xC0000005: Access violation reading location 0xA46FEC13.
EDIT 1:
verifier.dll has nothing to do with the error. It turns out this library is loaded when I added image file to gflags.exe in attempt to debug the program. After discarding these changes I got back to the original error message which is heap corruption raised by ntdll.dll.
EDIT 2:
I stripped down the code to the bare minimum by deleting all .h files and .cpp files till the error got away. This is very inefficient way to debug, yet since I did not know any better I did it anyway.
#include "MyGUI.h"
#include <boost/date_time/posix_time/posix_time.hpp>
[STAThread]
void main(array<String^>^ args) {
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
Application::Run(gcnew MyProject::MyGUI);
}
If I then remove the line
#include <boost/date_time/posix_time/posix_time.hpp>
then the problem goes away and the gui starts with no errors.
The reason why I got access violation error is because posix_time library silently links a .lib file. When I migrated from VS2012 to VS2015 I have rebuilt all the boost libraries in multiple variants and the additional library directories have been specified correctly in the project and contained the right variants of the libraries. I used posix_time library in other projects without problems however other projects were targeting x64 bit but the one I had a problem with is a x32 bit. I was linking x32 bit project against lib32 directory of my boost build, which is correct. It turns out that the reason why my application crashed was a bug in 32bit version of the posix_time library. Even linking my 32bit application to x64 folder resolves the problem. However, since I did not use microseconds,
BOOST_DATE_TIME_NO_LIB
compiler directive was sufficient. According to boost documentation,
The nano-second resolution option uses 96 bits of underlying storage for each ptime while the micro-second resolution uses 64 bits per ptime.
The latter quote and the fact that x64 bit library works fine makes me think that 32bit implementation of the library is faulty.
For those who might find it helpful - this was the reason. As for my original question how to debug such a crash when the heap corrupts even before the entry point is reached (and therefore no any source code or debug information is available) without wasting 7 hours to strip down the project till there is only one line left - I leave the question open.
If someone can point out a better approach to find such kind of errors - this will be very instructive.
EDIT 3:
Apparently this is not the end. After fixing boost libraries and reverting to the full code I got the error again. Problem is caused by use of a static variable in a GUI windows form method callback:
System::Void comboBoxStart_SelectionChangeCommitted(System::Object^ sender,
System::EventArgs^ e) {
static wstring LastChoice; //This line is enough to reproduce the crash
}
Can anyone explain why this leads to access violation reading location? Similar symptoms are described in this post.

Answer 1

Before loading your main, the executable will load dependent libraries and execute their own "main". It's a bit more complicated than that, but the important thing to understand is that code gets executed in those libraries first. If there are errors there, it will crash.
Your error message mentions that verifier.dll is the source of the problem. You should investigate that DLL first. Did you build it yourself? Does it have all required dependencies to run?

Answer 2

Access violation was caused by using static variables in managed code. I used a static variable of wstring type (native C++ type!) inside a windows form GUI callback (managed code). My guess is that the program tried to initialize the variable before the managed code initialization was over, causing the error before even reaching the program entry point.
After removing all static variables from managed code the problem disappeared.