Bugs, the art of finding them and divine intervention
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Erm ... are you sure?
m_pMainAppHandle == NULL;
Is a comparison, it shouldn't change a thing ... if it does, there is something really nasty going on your code!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Anytime there's an "else" I don't have time to think about (then and there), I add an Debug.Assert(false). Works better than trying to keep notes.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Erm ... are you sure?
m_pMainAppHandle == NULL;
Is a comparison, it shouldn't change a thing ... if it does, there is something really nasty going on your code!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
How can this test fix initialization...? Never mind, I just saw OG has mentioned this already.
- I would love to change the world, but they won’t give me the source code.
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
added some logging messages, started it up and the damn thing worked...EVC++
So one immediately knows it is a memory problem. Classic behavior. The new code changes the execution flow so the memory problem moves and no longer causes the initial problem. Very likely overwrite or underwrite (but overwrites tend to occur more often.)
charlieg wrote:
get a lint tool and use it
Memory check libraries with sufficient real data testing finds more problems.
-
Erm ... are you sure?
m_pMainAppHandle == NULL;
Is a comparison, it shouldn't change a thing ... if it does, there is something really nasty going on your code!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
Paul, you are definitivelly nitpicky and evil... ... ... ... I love it :laugh: :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Paul, you are definitivelly nitpicky and evil... ... ... ... I love it :laugh: :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
The Psychology of Nitpicking: Why Do People Nitpick? - Armani Talks[^] According to this article, I should feel empathy toward nitpickers. I, personally, still find it annoying. Its not anywhere close to evil.
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Yup, uninitialised variables isn't just a code smell, it's a stench. I get really picky about it now with my colleagues.
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Around 1983 I wrote a program in Canon BASIC for CPM/86 that managed a weekly magazine's store distribution. It kept a history of the number of magazines sold over the last 4 weeks and the number of returns. It then calculated what the next week's shipments should be. It had a cool onscreen entry form that looked just like their hand-written form. This dialect of BASIC used line numbering, could call subroutines, and it could chain to other programs, but it did not have the concept of libraries or database tools. I wrote my own indexing routines. They were copied and pasted across many of the chained programs that handled their aspects. There wasn't much in the way of debugging tools. I should also add this was my first major program that was being used for real world stuff. Program worked great most of the time, but my index would eventually get corrupted, and I would have to reindex. This would happen every month or two. The problem was this was a dual 8" disk system and doing the reindex took about 8 hours of banging on the drive. Pretty horrible. I don't remember what sort I used but I'm sure it was some variant of a bubble sort. I couldn't find the bug. We got a 20 MB hard drive in our office, and I started taking the data disk there copying it to the hard disk and reindexing. That only took 2 hours. I couldn't find the bug. One day I was working with it and had inspiration. I could load those items I'm indexing into an array and do the entire sort in RAM. Yes, I was a rookie in world by myself that it took so long to figure that out. Now indexing took about 20 minutes and didn't abuse the hardware. But I still couldn't find the bug. The magazine sold out to another company and now I had about a 50-minute drive one way. And the pressure to fix the bug was higher. I spent several Saturdays onsite staring at code when I found it. There was an incorrect comparison that involved the last item in the index. It didn't get triggered often so it rarely had the opportunity to corrupt. For some reason it was only one program that had it wrong. I suspect that after one of the copy and paste sessions I hit a key accidently and it changed that one comparison. Problem fixed after about 2 years. I never had to go back. And about six months later they folded that magazine's distribution processes into the minicomputer software they used for their other publications. I had discovered dBaSe II during that time and wished it was available to me when I created my application originally.
-
Around 1983 I wrote a program in Canon BASIC for CPM/86 that managed a weekly magazine's store distribution. It kept a history of the number of magazines sold over the last 4 weeks and the number of returns. It then calculated what the next week's shipments should be. It had a cool onscreen entry form that looked just like their hand-written form. This dialect of BASIC used line numbering, could call subroutines, and it could chain to other programs, but it did not have the concept of libraries or database tools. I wrote my own indexing routines. They were copied and pasted across many of the chained programs that handled their aspects. There wasn't much in the way of debugging tools. I should also add this was my first major program that was being used for real world stuff. Program worked great most of the time, but my index would eventually get corrupted, and I would have to reindex. This would happen every month or two. The problem was this was a dual 8" disk system and doing the reindex took about 8 hours of banging on the drive. Pretty horrible. I don't remember what sort I used but I'm sure it was some variant of a bubble sort. I couldn't find the bug. We got a 20 MB hard drive in our office, and I started taking the data disk there copying it to the hard disk and reindexing. That only took 2 hours. I couldn't find the bug. One day I was working with it and had inspiration. I could load those items I'm indexing into an array and do the entire sort in RAM. Yes, I was a rookie in world by myself that it took so long to figure that out. Now indexing took about 20 minutes and didn't abuse the hardware. But I still couldn't find the bug. The magazine sold out to another company and now I had about a 50-minute drive one way. And the pressure to fix the bug was higher. I spent several Saturdays onsite staring at code when I found it. There was an incorrect comparison that involved the last item in the index. It didn't get triggered often so it rarely had the opportunity to corrupt. For some reason it was only one program that had it wrong. I suspect that after one of the copy and paste sessions I hit a key accidently and it changed that one comparison. Problem fixed after about 2 years. I never had to go back. And about six months later they folded that magazine's distribution processes into the minicomputer software they used for their other publications. I had discovered dBaSe II during that time and wished it was available to me when I created my application originally.
I had a basic program on an Apple IIe which would fail if I added a comment. Yep presumably non executing code which would cause it to fail. Very repeatable. One or two years later I read an article that stated the Basic interpreter I was using had a bug that would cause it to incorrectly make a branch (goto?) when it occurred exactly on on a 256 byte boundary. Comments in the interpreter were rendered into a one byte do nothing token. So that was explained.
-
Erm ... are you sure?
m_pMainAppHandle == NULL;
Is a comparison, it shouldn't change a thing ... if it does, there is something really nasty going on your code!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
:) Today was a good day! Gotta love those impossible bugs that get solved. (It elates me when it happens to me.)
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
The most fun I had was with an app that had two threads. It worked perfectly fine - until hyperthreading showed up. There were about five software developers staring at the code for a day or two until someone finally noticed the bug. It's not good to tell the first thread that the second thread is done until it really is.
-
:laugh: The above statement with "==", not the original poster's "=", makes me look all over for your lol emoji.
There isn't one:
charlieg:
Oops, corrected.
:-D
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
charlieg wrote:
added some logging messages, started it up and the damn thing worked...EVC++
So one immediately knows it is a memory problem. Classic behavior. The new code changes the execution flow so the memory problem moves and no longer causes the initial problem. Very likely overwrite or underwrite (but overwrites tend to occur more often.)
charlieg wrote:
get a lint tool and use it
Memory check libraries with sufficient real data testing finds more problems.
Concur sort of. Windows CE and WEC7 are weird beasts. There OS memory models are like walking around with your fly down and no pants. For example, I can watch my dozen processes launch in this application, and they will typically be given the same address space. In the case of my uninitialized pointer, CE 5.0 helped me by zapping it such that I never caught it. On WEC7, the first time the application started there was garbage, so it would never work. Some time after startup, the value would be nulled out. The hard part here is that the HMI is part of the overall system, and the system controls the power. So, unless I go to special efforts, I always hit the first time startup bug. Like I admitted, I got lucky.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
The most fun I had was with an app that had two threads. It worked perfectly fine - until hyperthreading showed up. There were about five software developers staring at the code for a day or two until someone finally noticed the bug. It's not good to tell the first thread that the second thread is done until it really is.
-
Anytime there's an "else" I don't have time to think about (then and there), I add an Debug.Assert(false). Works better than trying to keep notes.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
I agree. I just fixed a bug in SEC (somebody else’s code) where they loaded an override parameter, printed a warning if it was empty, then proceeded to use it even if it was empty. WTF? Corrected code added an else and covered both if and else clauses.
-
Been trying to find this "bug" for 3+ years. It lives in a critical piece of code for a specific oem. One of the first rules of debugging is to determine if you can repeat the behavior, etc. It's very easy to go off shotgunning, etc. so step 1 is to answer, "What changed?" What works (we're going back to 2009): WinCE 5.0, EVC++, embedded IE browser in CE 5.0, activeX controls, javascript and vbscript. What changed: OS to WEC7, VS2008, a new half baked embedded IE browser in WEC7, minor edits to the code to make it happy with VS2008, and new hardware. Beginning to see the problem? :) what could go wrong? So, just about everything changed except the application. Where my bug lurks. So, last week I was taking another stab at obtaining data as to the problem (the oem supplied web page doesn't run, the activeX controls don't behave). Started up the debugger, application hung - same behavior as before. Shut it down, added some logging messages, started it up and the damn thing worked. First time I had seen this, and we're now into divine intervention mode. Yeah, I know, you can call it blind luck. :) I have an initialization problem. In about an hour, I tracked down the "bug" to lack of initialization of a pointer in an activeX control. EVC++ and CE 5.0 had no issue with the code and always behaved. WEC7 had trash in the pointer (why we initialize things). It was a 15 year old cut/paste oversight. Yeah me. Learning points: get a lint tool and use it. Going back to 2005, running mfc applications caused lint tools to explode with complaints, so we never got serious about it. Going to have to dust the issue off. Here's the missing line of code: "m_pMainAppHandle = NULL;" Sometimes I love my job, sometimes I want to cry. Just get in the habit of watching for uninitialized member variables. Simple issues like this are caught by source code tools, but this is something that should always be done.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I feel for you. But there is a certain sense of satisfaction when you do figure it out after so long....
