Once Again Assert in Release and I am lost
-
Hi I got a debug assertion in Release the VC c run time Message Box is nice enough to give me the source and line number wincore.cpp line 656 its in CreateHook asserting m_hWnd == NULL well this is in a process of Creating a modeless dialog box with 5 controls all CStatic I check the m_hWnd of each of the 5 right after the call to base fundtion CDialog::OinitDialog which calls DataExchange routine to create the m_hWnd's and issue a AfxMessagebox in case any of the handles are NULL I also check it right before I do a return in my overridable OninitDailog in case I somehow overlaid the handle I also check the Return code from CDialog::Create Any advice would be appreciated
ForNow wrote:
I got a debug assertion in Release...
I'm not sure how since the
ASSERT()macro resolves to a no-op in release mode. Does the same assertion fire in debug mode?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
ForNow wrote:
I got a debug assertion in Release...
I'm not sure how since the
ASSERT()macro resolves to a no-op in release mode. Does the same assertion fire in debug mode?"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
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
-
Hi I got a debug assertion in Release the VC c run time Message Box is nice enough to give me the source and line number wincore.cpp line 656 its in CreateHook asserting m_hWnd == NULL well this is in a process of Creating a modeless dialog box with 5 controls all CStatic I check the m_hWnd of each of the 5 right after the call to base fundtion CDialog::OinitDialog which calls DataExchange routine to create the m_hWnd's and issue a AfxMessagebox in case any of the handles are NULL I also check it right before I do a return in my overridable OninitDailog in case I somehow overlaid the handle I also check the Return code from CDialog::Create Any advice would be appreciated
You should find out first why your release build is linked with the debug version of the MFC. Is this still the same project where you already recognised this? If yes, I guess that there is something wrong with your release project settings. You might use the Dependency Walker (depends.exe) Home Page[^] to check which DLL's are required by your application. Note also that there are two definitions which are set accordingly when selecting the project build option:
NDEBUGand_DEBUG. You should not change these. If you need to do so, create a special build instead of modifying the standard release or debug settings. -
You should find out first why your release build is linked with the debug version of the MFC. Is this still the same project where you already recognised this? If yes, I guess that there is something wrong with your release project settings. You might use the Dependency Walker (depends.exe) Home Page[^] to check which DLL's are required by your application. Note also that there are two definitions which are set accordingly when selecting the project build option:
NDEBUGand_DEBUG. You should not change these. If you need to do so, create a special build instead of modifying the standard release or debug settings. -
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