I want to prevent an error from occurring when a program that uses a DLL is executed in debug mode.
The DLL was created as an MFC DLL in VisualStudio2015, and the released version is used.

Thank you.

Error message
An unhandled exception occurred at 0x6E1CD930 (vcruntime140.dll) (in DataRay.exe): 0xC0000005: An access violation occurred while reading location 0x001F1000.
If i have a handler for this exception, you can safely continue your program.

The error message appears, and the debugger stops at the line that calls the function of your DLL.


Adding your own DLL project to the solution of the project i am using and adding it to the reference eliminates the error.
Also, once the error no longer occurs, no further error will occur if you try to unload your own DLL project or remove the reference from the solution.
Since I do the same with multiple solutions, I want to avoid this method because I want to avoid "I accidentally rewrote my DLL code!"

Supplemental information (FW/tool version etc.)
  • Windows7/64bit SP
  • VisualStudio2015 SP1
  • C ++/MFC
Added to 2018-08-27

The situation changed slightly when .dll, .lib, and .h files that were built in Debug mode in the same environment were placed in a program that uses the DLL.
A linker error occurs and a .lib file is requested under the Debug directory in the same directory as the solution file.
The same error will eventually occur after deployment.
Also, the linker should have specified a .lib file under the lib directory, but it seems to be mysterious that the linker error can be resolved by placing it directly under the Debug directory ...

2018-08-28 update

When I debug this morning, VisualStudio gets angry if the DLL version is different.
It doesn't occur when you rebuild the DLL and re-arrange it, etc. while thinking, nothing has changed ...
It's a strange story even though I haven't done any DLL program or rework. The fairy may have fixed it. (It ’s a mystery what has changed since I did n’t joke and have n’t made any changes recently.)
Anyway, because I was able to confirm that it works in the way I taught, I chose the best answer.

  • Answer # 1

    Although you may have removed it, I will point out the point that I was worried about because it is MFC DLL.

    If the DLL side is a Release build and the exe side is a Debug build, I think that an error occurred when exchanging data such as CString between the DLL and the exe.

    The detailed contents are a bit suspicious, but since the MFC library in debug mode that is called on the exe side is also used on the DLL side, trying to use the MFC class on the exe side on the DLL side that was released and built I remembered that it was an exception when the memory mapping was different.

    The solution is to use the debug built DLL when debugging exe, even if it is not in the same project.

    Try it now.