Breakpoints in Wincore.cpp
-
I have been trying to correct an assertion failure in an MFC app for the last few days. It's been really fun... while the rest of you have been doing boring things like riding your outlandish motorcycles or bar-hopping with your chubby girlfriends, I get to really spend some quality time trying to comprehend things like "___Afx_4_U_T_q_HowDoesThisEvenCompile_". Anyhoo... an assertion fails somewhere in Wincore.cpp (a local called pMap comes up as 0, implying a call from the wrong thread, I am thinking). When the failure occurs, Visual Studio breaks into Wincore.cpp (which it finds and opens) and does a good job of debugging. It shows a call stack, "Watch" and "Quickwatch" seem to work, etc. The problem arises when I try to do some manual editing to Wincore.cpp, or even just set a breakpoint in Wincore.cpp. It quickly becomes obvious that even though Visual Studio itself found and opened this file just a moment ago, it is not actually using the copy of Wincore.cpp that I am seeing as part of the build process. So, I can make garbage edits to it, do a "Rebuild All," and still get no errors. This seems completely wrong to me and provokes my ire at a very fundamental level. I mean, I guess Microsoft and I have different definitions of terms like "compile" and "source code." When I try to simply set a breakpoint in Wincore.cpp without changing it, the breakpoint's red dot indicator goes "hollow" at runtime. When I hover over the breakpoint, Visual Studio tells me that the source code is different from that used in compilation. If I check "allow location to be different" in the breakpoint properties, then the breakpoint gets hit, but Visual Studio claims to have no source code. It prompts me to browse to the original source code. Strangely, there is a text field in this dialog showing where the source code originally resided, and this is some path on F:-drive (which, in my case, is a removable flash drive that isn't even present in the system). I'm not sure how much more "original" I can get than the file I'm TRYING to use, which is in a subfolder of C:\Program Files\Microsoft Visual Studio 2008\ and was opened up for me by Visual Studio. Am I expected to e-mail Raymond Chen for the copy on his hard drive perhaps? Generally, I don't need to edit Wincore.cpp; I would never do this permanently. Also, I suppose I haven't had much experience setting breakpoints in that file. However, I think that what I am trying to do should be possible, and I think that Visual Studio's behavior is very misleading. Am I
-
I have been trying to correct an assertion failure in an MFC app for the last few days. It's been really fun... while the rest of you have been doing boring things like riding your outlandish motorcycles or bar-hopping with your chubby girlfriends, I get to really spend some quality time trying to comprehend things like "___Afx_4_U_T_q_HowDoesThisEvenCompile_". Anyhoo... an assertion fails somewhere in Wincore.cpp (a local called pMap comes up as 0, implying a call from the wrong thread, I am thinking). When the failure occurs, Visual Studio breaks into Wincore.cpp (which it finds and opens) and does a good job of debugging. It shows a call stack, "Watch" and "Quickwatch" seem to work, etc. The problem arises when I try to do some manual editing to Wincore.cpp, or even just set a breakpoint in Wincore.cpp. It quickly becomes obvious that even though Visual Studio itself found and opened this file just a moment ago, it is not actually using the copy of Wincore.cpp that I am seeing as part of the build process. So, I can make garbage edits to it, do a "Rebuild All," and still get no errors. This seems completely wrong to me and provokes my ire at a very fundamental level. I mean, I guess Microsoft and I have different definitions of terms like "compile" and "source code." When I try to simply set a breakpoint in Wincore.cpp without changing it, the breakpoint's red dot indicator goes "hollow" at runtime. When I hover over the breakpoint, Visual Studio tells me that the source code is different from that used in compilation. If I check "allow location to be different" in the breakpoint properties, then the breakpoint gets hit, but Visual Studio claims to have no source code. It prompts me to browse to the original source code. Strangely, there is a text field in this dialog showing where the source code originally resided, and this is some path on F:-drive (which, in my case, is a removable flash drive that isn't even present in the system). I'm not sure how much more "original" I can get than the file I'm TRYING to use, which is in a subfolder of C:\Program Files\Microsoft Visual Studio 2008\ and was opened up for me by Visual Studio. Am I expected to e-mail Raymond Chen for the copy on his hard drive perhaps? Generally, I don't need to edit Wincore.cpp; I would never do this permanently. Also, I suppose I haven't had much experience setting breakpoints in that file. However, I think that what I am trying to do should be possible, and I think that Visual Studio's behavior is very misleading. Am I
I see you're using VS 2008. I know that when an MFC application initialises, the function
AfxGetThread()in thrdcore.cppwill be called. I was able to set a breakpoint on that function, without even opening the file. I chose Debug->New BreakPoint->Break at function-> enter function name asAfxGetThread()and set line and character as 1 each. When I hit F5, the debugger opened thrdcore.cpp and broke at the beginning ofAfxGetThread(). You might want to try it with the function of your interest located inwincore.cpp. The IDE will open the correct file (that it is using), and break at the location of your interest. You might as well consider using "Advanced breakpoints" (just do a search). :)“Follow your bliss.” – Joseph Campbell
-
I have been trying to correct an assertion failure in an MFC app for the last few days. It's been really fun... while the rest of you have been doing boring things like riding your outlandish motorcycles or bar-hopping with your chubby girlfriends, I get to really spend some quality time trying to comprehend things like "___Afx_4_U_T_q_HowDoesThisEvenCompile_". Anyhoo... an assertion fails somewhere in Wincore.cpp (a local called pMap comes up as 0, implying a call from the wrong thread, I am thinking). When the failure occurs, Visual Studio breaks into Wincore.cpp (which it finds and opens) and does a good job of debugging. It shows a call stack, "Watch" and "Quickwatch" seem to work, etc. The problem arises when I try to do some manual editing to Wincore.cpp, or even just set a breakpoint in Wincore.cpp. It quickly becomes obvious that even though Visual Studio itself found and opened this file just a moment ago, it is not actually using the copy of Wincore.cpp that I am seeing as part of the build process. So, I can make garbage edits to it, do a "Rebuild All," and still get no errors. This seems completely wrong to me and provokes my ire at a very fundamental level. I mean, I guess Microsoft and I have different definitions of terms like "compile" and "source code." When I try to simply set a breakpoint in Wincore.cpp without changing it, the breakpoint's red dot indicator goes "hollow" at runtime. When I hover over the breakpoint, Visual Studio tells me that the source code is different from that used in compilation. If I check "allow location to be different" in the breakpoint properties, then the breakpoint gets hit, but Visual Studio claims to have no source code. It prompts me to browse to the original source code. Strangely, there is a text field in this dialog showing where the source code originally resided, and this is some path on F:-drive (which, in my case, is a removable flash drive that isn't even present in the system). I'm not sure how much more "original" I can get than the file I'm TRYING to use, which is in a subfolder of C:\Program Files\Microsoft Visual Studio 2008\ and was opened up for me by Visual Studio. Am I expected to e-mail Raymond Chen for the copy on his hard drive perhaps? Generally, I don't need to edit Wincore.cpp; I would never do this permanently. Also, I suppose I haven't had much experience setting breakpoints in that file. However, I think that what I am trying to do should be possible, and I think that Visual Studio's behavior is very misleading. Am I
Member 3680785 wrote:
It quickly becomes obvious that even though Visual Studio itself found and opened this file just a moment ago, it is not actually using the copy of Wincore.cpp that I am seeing as part of the build process. So, I can make garbage edits to it, do a "Rebuild All," and still get no errors. This seems completely wrong to me and provokes my ire at a very fundamental level. I mean, I guess Microsoft and I have different definitions of terms like "compile" and "source code."
I think that wincore.cpp is provided for debugging purposes only, MFC can't be compiled easily from the source. What your app links to is the debug versions of MFC dlls. As for VS finding the source that's probably because it is referenced in the dll or some pch file or some such.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition. Blaise Pascal
-
I have been trying to correct an assertion failure in an MFC app for the last few days. It's been really fun... while the rest of you have been doing boring things like riding your outlandish motorcycles or bar-hopping with your chubby girlfriends, I get to really spend some quality time trying to comprehend things like "___Afx_4_U_T_q_HowDoesThisEvenCompile_". Anyhoo... an assertion fails somewhere in Wincore.cpp (a local called pMap comes up as 0, implying a call from the wrong thread, I am thinking). When the failure occurs, Visual Studio breaks into Wincore.cpp (which it finds and opens) and does a good job of debugging. It shows a call stack, "Watch" and "Quickwatch" seem to work, etc. The problem arises when I try to do some manual editing to Wincore.cpp, or even just set a breakpoint in Wincore.cpp. It quickly becomes obvious that even though Visual Studio itself found and opened this file just a moment ago, it is not actually using the copy of Wincore.cpp that I am seeing as part of the build process. So, I can make garbage edits to it, do a "Rebuild All," and still get no errors. This seems completely wrong to me and provokes my ire at a very fundamental level. I mean, I guess Microsoft and I have different definitions of terms like "compile" and "source code." When I try to simply set a breakpoint in Wincore.cpp without changing it, the breakpoint's red dot indicator goes "hollow" at runtime. When I hover over the breakpoint, Visual Studio tells me that the source code is different from that used in compilation. If I check "allow location to be different" in the breakpoint properties, then the breakpoint gets hit, but Visual Studio claims to have no source code. It prompts me to browse to the original source code. Strangely, there is a text field in this dialog showing where the source code originally resided, and this is some path on F:-drive (which, in my case, is a removable flash drive that isn't even present in the system). I'm not sure how much more "original" I can get than the file I'm TRYING to use, which is in a subfolder of C:\Program Files\Microsoft Visual Studio 2008\ and was opened up for me by Visual Studio. Am I expected to e-mail Raymond Chen for the copy on his hard drive perhaps? Generally, I don't need to edit Wincore.cpp; I would never do this permanently. Also, I suppose I haven't had much experience setting breakpoints in that file. However, I think that what I am trying to do should be possible, and I think that Visual Studio's behavior is very misleading. Am I
Hi, I just wanted to add some observations. You state in your message novel that the variable pMap is NULL. I recognize this variable name as possibly being the internel MFC CHandleMap. If this variable is NULL then you are incorrectly accessing MFC objects across a thread boundry. I would suggest that you research the following: Description of CWnd derived MFC objects and multithreaded applications in Visual C++[^] Inside MFC: Handle Maps and Temporary Objects[^] Best Wishes, -David Delaune