Once Again Assert in Release and I am lost
-
I have an idea The .lib I pointing to ucrt has both debug and release libs Libcrt and libcrtd If I just point it to the one with libcrt Then those functions which require the debug build (erroneously ) should be unresolved
Why have you specified the CRT library in the project settings? It is automatically selected according to the /M build option (static/dynamic, release/debug). You should still use the Dependency Walker to check if there are more debug DLLs referenced.
-
Why have you specified the CRT library in the project settings? It is automatically selected according to the /M build option (static/dynamic, release/debug). You should still use the Dependency Walker to check if there are more debug DLLs referenced.
-
No my code works fine under the Visual Studio debugger Other funny thing after selecting re-try and attaching the VS debugger the call stack points to the debugging version of MFC140 - MFC140D.DLL the only thing I included in my libs per Microsoft doc were the UCRT .libs from the windows 10 sdk I have preprocessor NDEBUG flag just wondering if that might cause this
NDEBUG it is defined by C/C++ standards to control what assert does. assert - cppreference.com[^] Visual Studio will redirect it in release build to try and do something useful but probably wrong and you are welcome to override it. Visual Studio itself uses it's own two macros to control build/release modes Predefined Macros[^] _DEBUG Defined as 1 when the /LDd, /MDd, or /MTd compiler option is set. Otherwise, undefined. _DLL Defined as 1 when the /MD or /MDd (Multithreaded DLL) compiler option is set. Otherwise, undefined. You seem to be getting confused between what is demanded by C/C++ standards and what VS does itself. Assert functionality lies outside VS control as demanded by the C/C++ standard. Now at a guess what you have a wrong DLL dependency like the console using msvcrd.lib rather than msvcr.lib. If you are dragging in other libraries you need to make sure those other libraries are also compiled in release mode. So what other libraries are you linking with and are they added in your project source list. AKA do you see them compile when you do a full build or are you just dragging in pre-compiled units. There are a number of dependency walkers out there you can run on your exe to see what DLL's it calls hit your favourite search engine. You shouldn't need them and I don't use them (so can't recommend one) but they are out there.
In vino veritas
-
Why have you specified the CRT library in the project settings? It is automatically selected according to the /M build option (static/dynamic, release/debug). You should still use the Dependency Walker to check if there are more debug DLLs referenced.
Okay I finally ran dependency walker was absolutely no help all it told me that my module was dependent on MFC140D.DLL but which api Pulled this in ? Next I turned to DUMPBIN a little more usefull but not by much so I used the /IMPORT option to see what calls my .exe is referencing from the Microsoft DLL's By the way as a side not I ensure that both my native CRT call and MFC were dynamic wanted to be consistent well for the regular windows .DLL as USER and GDI it (DUMPBIN) told me the API my program was referencing Getting to MFC or MFC140D.DLL is became more secretive just showing the ordinal number
-
Okay I finally ran dependency walker was absolutely no help all it told me that my module was dependent on MFC140D.DLL but which api Pulled this in ? Next I turned to DUMPBIN a little more usefull but not by much so I used the /IMPORT option to see what calls my .exe is referencing from the Microsoft DLL's By the way as a side not I ensure that both my native CRT call and MFC were dynamic wanted to be consistent well for the regular windows .DLL as USER and GDI it (DUMPBIN) told me the API my program was referencing Getting to MFC or MFC140D.DLL is became more secretive just showing the ordinal number
You missed a library somehow. Hmmm what I might try is temporarily rename MFC140D.DLL and try a rebuild and hopefully you get a linker error.
In vino veritas
-
You missed a library somehow. Hmmm what I might try is temporarily rename MFC140D.DLL and try a rebuild and hopefully you get a linker error.
In vino veritas
I did that and I got a whole slew of errors all related to the MFC wrappers my question would be then is there any difference between MFC140D and MFC140 I mean just the api's it exposes I am getting a whole slew of errors asserts and I am trying to track down the problem by removing piece by piece of my code related to the CDilaog which seems to be the problem I don't think its the fact that I am running with MFC140D as opposed to MFC140 Thanks
-
I did that and I got a whole slew of errors all related to the MFC wrappers my question would be then is there any difference between MFC140D and MFC140 I mean just the api's it exposes I am getting a whole slew of errors asserts and I am trying to track down the problem by removing piece by piece of my code related to the CDilaog which seems to be the problem I don't think its the fact that I am running with MFC140D as opposed to MFC140 Thanks
-
I did that and I got a whole slew of errors all related to the MFC wrappers my question would be then is there any difference between MFC140D and MFC140 I mean just the api's it exposes I am getting a whole slew of errors asserts and I am trying to track down the problem by removing piece by piece of my code related to the CDilaog which seems to be the problem I don't think its the fact that I am running with MFC140D as opposed to MFC140 Thanks
You obviously have a real mess with the solution files. I think at this point I would either copy the directory and delete all the solution files or simply make a new directory and just copy the source files into it. Then set the solution up from new with the new directory with no existing solution files. I think that has to be the fastest way to solve it because it really shouldn't be this hard, its a lot less effort than what you are going thru.
In vino veritas
-
You obviously have a real mess with the solution files. I think at this point I would either copy the directory and delete all the solution files or simply make a new directory and just copy the source files into it. Then set the solution up from new with the new directory with no existing solution files. I think that has to be the fastest way to solve it because it really shouldn't be this hard, its a lot less effort than what you are going thru.
In vino veritas
Leon my thinking exactly I'll start from scratch (except for the source code) when I first created the solution project I knew very little about the components I do now have a better idea there are basically 3 components 1) C run time library such as sprintf 2) Windows native code user32 gdi etc.. 3) the mfc wrappers I am basically going to shared or dynamic linking for all three as opposed to static Thanks
-
I did that and I got a whole slew of errors all related to the MFC wrappers my question would be then is there any difference between MFC140D and MFC140 I mean just the api's it exposes I am getting a whole slew of errors asserts and I am trying to track down the problem by removing piece by piece of my code related to the CDilaog which seems to be the problem I don't think its the fact that I am running with MFC140D as opposed to MFC140 Thanks
Well At Leon's suggestion I started from scratch with a solution copying my code in Guess what I noticed I had SetThreadName still my code. Obviously with no debugger this would cause problems I am not by trade a Windows programmer but I will say this there seems to be somewhat of a window for (errors going from debug to release) as having MFC140D.DLL in my module list I put MFC140.LIB as input to my linker to get rid of that problems Again thanks to all who have been helping me