V2008: All my breakpoints disable. Mouseover shows "The breakpoint will not currently be hit. No executable code is associated with this line."
-
Ripping my hair out with this one. I develop for some Windows Embedded Compact 7 products where we use VS2008 with add-on SDKs. All service packs applied, I've been using the same setup for the A week or so ago, I did a code merge between two branches and broke on of my applications. In trying to debug the issue, I discovered that no matter where I placed breakpoints, they would immediately go clear with a warning. Mousing over shows the message in the title bar. In doing my debug of the debugger work, I have: - full clean rebuild; - delete all PDB, suo and ncb files; - create a new application; Nothing corrects the issue. In fact, the last item is a simple dummy hello world dialog app, and it has the same breakpoint issue. So something bad has happened to the installation I'm guessing. In reading all the SO discussions, it appears that most people solve this by making random changes until it starts working. Does anyone have a definitive explanation or solution for this behavior? Thanks
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Ripping my hair out with this one. I develop for some Windows Embedded Compact 7 products where we use VS2008 with add-on SDKs. All service packs applied, I've been using the same setup for the A week or so ago, I did a code merge between two branches and broke on of my applications. In trying to debug the issue, I discovered that no matter where I placed breakpoints, they would immediately go clear with a warning. Mousing over shows the message in the title bar. In doing my debug of the debugger work, I have: - full clean rebuild; - delete all PDB, suo and ncb files; - create a new application; Nothing corrects the issue. In fact, the last item is a simple dummy hello world dialog app, and it has the same breakpoint issue. So something bad has happened to the installation I'm guessing. In reading all the SO discussions, it appears that most people solve this by making random changes until it starts working. Does anyone have a definitive explanation or solution for this behavior? Thanks
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Seems I fixed this by doing a repair installation on VS2008. Should have thought of that last week.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Seems I fixed this by doing a repair installation on VS2008. Should have thought of that last week.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
The bigger question is why you are still using VS2008 given all the upgrades above you are free :-) WIN CE was supported until at least VS2015 from memory. Update: Ignore that you are trying to debug you have to be on VS2008 my bad
In vino veritas
-
The bigger question is why you are still using VS2008 given all the upgrades above you are free :-) WIN CE was supported until at least VS2015 from memory. Update: Ignore that you are trying to debug you have to be on VS2008 my bad
In vino veritas
In principle, you can choose a toolset from an earlier VS installation in any version of VS. If VS 2008 and a newer version are installed, you should be able to select the VS 2008 toolset in the newer VS for the purpose of debugging, or even building executables. Maybe intellisense won't like it, but you can disable intellisense if it gets too annoying.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
In principle, you can choose a toolset from an earlier VS installation in any version of VS. If VS 2008 and a newer version are installed, you should be able to select the VS 2008 toolset in the newer VS for the purpose of debugging, or even building executables. Maybe intellisense won't like it, but you can disable intellisense if it gets too annoying.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Pretty sure you have to have a stub running in Win CE target to debug and if I remember correctly it is tied to the VS version. You can definitely compile without issue but I recall issues with debugging.
In vino veritas
-
Pretty sure you have to have a stub running in Win CE target to debug and if I remember correctly it is tied to the VS version. You can definitely compile without issue but I recall issues with debugging.
In vino veritas
Good point. I've never tried this with different target platform applications.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
The bigger question is why you are still using VS2008 given all the upgrades above you are free :-) WIN CE was supported until at least VS2015 from memory. Update: Ignore that you are trying to debug you have to be on VS2008 my bad
In vino veritas
Good question, but it's the nature of embedded systems. My customers are still using systems they purchased in 2006. We're still supporting CE 5.0 and WEC7. Microsoft sort of lost their way after WEC7, and the tools stopped supporting the embedded arena. Microsoft was ripped a new bloody one with this decision, and eventually added support back into the Visual Studio, but the support does not extend back to 5.0 and 7.0. My team dug into this pretty deeply a few years back when we had to deal with this. Do you have knowledge of this changing?
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Ripping my hair out with this one. I develop for some Windows Embedded Compact 7 products where we use VS2008 with add-on SDKs. All service packs applied, I've been using the same setup for the A week or so ago, I did a code merge between two branches and broke on of my applications. In trying to debug the issue, I discovered that no matter where I placed breakpoints, they would immediately go clear with a warning. Mousing over shows the message in the title bar. In doing my debug of the debugger work, I have: - full clean rebuild; - delete all PDB, suo and ncb files; - create a new application; Nothing corrects the issue. In fact, the last item is a simple dummy hello world dialog app, and it has the same breakpoint issue. So something bad has happened to the installation I'm guessing. In reading all the SO discussions, it appears that most people solve this by making random changes until it starts working. Does anyone have a definitive explanation or solution for this behavior? Thanks
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Well, I spoke to soon :sigh: . The re-installation did not fix this completely. My breakpoints are back, but any attempts at compiling is a disaster. There was an issue from long ago (I even have notes back from 2017 on this) about issues with the default include order. My notes cover about 95% of what needs to be done to correct it, but I think I missed one important key. Sigh. I'm backing up to a scrubbed system and re-installing everything. VMs are nice.
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
-
Ripping my hair out with this one. I develop for some Windows Embedded Compact 7 products where we use VS2008 with add-on SDKs. All service packs applied, I've been using the same setup for the A week or so ago, I did a code merge between two branches and broke on of my applications. In trying to debug the issue, I discovered that no matter where I placed breakpoints, they would immediately go clear with a warning. Mousing over shows the message in the title bar. In doing my debug of the debugger work, I have: - full clean rebuild; - delete all PDB, suo and ncb files; - create a new application; Nothing corrects the issue. In fact, the last item is a simple dummy hello world dialog app, and it has the same breakpoint issue. So something bad has happened to the installation I'm guessing. In reading all the SO discussions, it appears that most people solve this by making random changes until it starts working. Does anyone have a definitive explanation or solution for this behavior? Thanks
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
I'm going to close this out for posterity's sake. Part of the problem with having to use VS2008 is that people who make extensions don't test against very old versions, and let's face it, 2008 is a gnarly old thing (but it's better than EVC++). Anyway, a long about December of last year I was trying to track down an issue with stack allocation. One tool I tried to use is Intel's VTune. Once installed, my woes began. I scrubbed everything to recover. Not only did it hose the breakpoints, but things would not compile, etc. I'm a busy guy, and I hate not being able to go back and do a true cause analysis. New post coming up :)
Charlie Gilley <italic>Stuck in a dysfunctional matrix from which I must escape... "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759