I've seen a ton of posts about similar problems, but none of the solutions
were effective. I've been maintaining this VB code for 3 years, and this is
the first time this has happened. It seems that the first one or two
breakpoints encountered trigger, but after that, none of my other breakpoints
work. Also, when the breakpoints stop working, the debugger seems to lose
track of what module the executing code is in, because when the fatal error
occurs, the debugger also complains that there is "no source code for the
current location." I know the exact line it's failing on! This is making
development absolutely impossible.

"Lost In The Woods" <(E-Mail Removed)> wrote in
message news:0EF5CDB0-731C-420E-89EF-(E-Mail Removed)...
> I've seen a ton of posts about similar problems, but none of the solutions
> were effective. I've been maintaining this VB code for 3 years, and this
> is
> the first time this has happened. It seems that the first one or two
> breakpoints encountered trigger, but after that, none of my other
> breakpoints
> work. Also, when the breakpoints stop working, the debugger seems to lose
> track of what module the executing code is in, because when the fatal
> error
> occurs, the debugger also complains that there is "no source code for the
> current location." I know the exact line it's failing on! This is making
> development absolutely impossible.

I contracted in a company that had VS2003 on their brand new machines
running XP Pro. The had replaced the old machines with new ones, because of
debugging problems similar to your problems with the old machines that were
not that old. The new machines had more memory, but it didn't correct the
problem. Well, it came to be that the page file size that the O/S was using
(XP) was not set correctly. It was a page file size that was set to low,
which was causing VS2003's debugger to start having problems when debugging
code. The solution was to set the page file size to be automatically
controlled by the O/S. After the page file size was corrected, they never
had another problem with the VS2003 debugger in debugging code.

Thanks for your reply. I changed the paging settings and unfortunately the
debugger continues to ignore my breakpoints. However, I have discovered
something interesting. I'm using MySQL and it would appear that opening the
database is causing the failure. If I comment out the code, all the
breakpoints that were failing before start working. I'm sure it's not a code
path issue. There appears to be some kind of insidious memory related
problem happening here. I can debug the particular piece of code I'm working
on without having the database open. God help me when that's not the case...

"Mr. Arnold" wrote:

>
> "Lost In The Woods" <(E-Mail Removed)> wrote in
> message news:0EF5CDB0-731C-420E-89EF-(E-Mail Removed)...
> > I've seen a ton of posts about similar problems, but none of the solutions
> > were effective. I've been maintaining this VB code for 3 years, and this
> > is
> > the first time this has happened. It seems that the first one or two
> > breakpoints encountered trigger, but after that, none of my other
> > breakpoints
> > work. Also, when the breakpoints stop working, the debugger seems to lose
> > track of what module the executing code is in, because when the fatal
> > error
> > occurs, the debugger also complains that there is "no source code for the
> > current location." I know the exact line it's failing on! This is making
> > development absolutely impossible.
>
> I contracted in a company that had VS2003 on their brand new machines
> running XP Pro. The had replaced the old machines with new ones, because of
> debugging problems similar to your problems with the old machines that were
> not that old. The new machines had more memory, but it didn't correct the
> problem. Well, it came to be that the page file size that the O/S was using
> (XP) was not set correctly. It was a page file size that was set to low,
> which was causing VS2003's debugger to start having problems when debugging
> code. The solution was to set the page file size to be automatically
> controlled by the O/S. After the page file size was corrected, they never
> had another problem with the VS2003 debugger in debugging code.
>
>