We've been getting some strange errors on an Excel VBA project:

On random computers, it stops on random lines as if at a breakpoint,
but there is no breakpoint there; in fact it sometimes happens when a
non-programmer just opens the Excel file and clicks a control to run a
macro. Since VBA doesn't save breakpoints, it obviously isn't a real
breakpoint.

It isn't stopping on an error in those instances, because once it
stops like that, it will happily proceed without error if you simply
press F5.


On the same project, we've also been getting random bogus compile
errors, as if a referenced variable, form, etc. did not exist. Once it
even did it on Excel VBA's built-in Right function, as if Excel VBA's
Right function did not exist. But if we copy the workbook to another
computer, or try again later on the same computer, it runs without
error.


I'm guessing workbook corruption, but is there anything else I should
be looking at too?

Here's what I tried just now:
-- Copied all worksheets to new workbook.
-- Added the required references to the new workbook.
-- For each module and class module, copied text of module into
new module.
-- Copied code behind workbook module.
-- Copied all forms.

I'm doing most of the development in Excel 2007, and users are mixed
between Excel 2007 and 2003. On previous projects, I've also seen the
random phantom breakpoint problem on a project done only in Excel
2003.

Any other suggestions?


Thanks,

Greg

it's a problem of cpu usage
explore through task bar
--
hemu


"Greg Lovern" wrote:

We've been getting some strange errors on an Excel VBA project:

On random computers, it stops on random lines as if at a breakpoint,
but there is no breakpoint there; in fact it sometimes happens when a
non-programmer just opens the Excel file and clicks a control to run a
macro. Since VBA doesn't save breakpoints, it obviously isn't a real
breakpoint.

It isn't stopping on an error in those instances, because once it
stops like that, it will happily proceed without error if you simply
press F5.


On the same project, we've also been getting random bogus compile
errors, as if a referenced variable, form, etc. did not exist. Once it
even did it on Excel VBA's built-in Right function, as if Excel VBA's
Right function did not exist. But if we copy the workbook to another
computer, or try again later on the same computer, it runs without
error.


I'm guessing workbook corruption, but is there anything else I should
be looking at too?

Here's what I tried just now:
-- Copied all worksheets to new workbook.
-- Added the required references to the new workbook.
-- For each module and class module, copied text of module into
new module.
-- Copied code behind workbook module.
-- Copied all forms.

I'm doing most of the development in Excel 2007, and users are mixed
between Excel 2007 and 2003. On previous projects, I've also seen the
random phantom breakpoint problem on a project done only in Excel
2003.

Any other suggestions?


Thanks,

Greg

Huh??

So you're saying if the CPU is busy, instead of just slowing down,
Excel (a) opens the VBE, and then either (b1) pauses at a line of code
as if at a breakpoint, or (b2) reports that a valid referenced item,
such as a variable, form, built-in Excel function, etc., does not
exist?

I've seen Excel do some crazy things over the years, but that really
takes the cake. Can anyone confirm that hemu is correct?

Or are you (hemu) joking?

Also, what do you mean by "explore through the task bar". Everyone
involved is using Windows XP; how do I "explore" this issue with the
Windows XP taskbar?

No one has yet reported the problem again since I did the workbook
corruption repair tasks yesterday, but I assume everyone's CPU is
probably about as busy as usual.

Greg


On Feb 11, 7:56 pm, Hemant_india
wrote:
it's a problem of cpu usage
explore through task bar
--
hemu

"Greg Lovern" wrote:
We've been getting some strange errors on an Excel VBA project:

On random computers, it stops on random lines as if at a breakpoint,
but there is no breakpoint there; in fact it sometimes happens when a
non-programmer just opens the Excel file and clicks a control to run a
macro. Since VBA doesn't save breakpoints, it obviously isn't a real
breakpoint.

It isn't stopping on an error in those instances, because once it
stops like that, it will happily proceed without error if you simply
press F5.

On the same project, we've also been getting random bogus compile
errors, as if a referenced variable, form, etc. did not exist. Once it
even did it on Excel VBA's built-in Right function, as if Excel VBA's
Right function did not exist. But if we copy the workbook to another
computer, or try again later on the same computer, it runs without
error.

I'm guessing workbook corruption, but is there anything else I should
be looking at too?

Here's what I tried just now:
-- Copied all worksheets to new workbook.
-- Added the required references to the new workbook.
-- For each module and class module, copied text of module into
new module.
-- Copied code behind workbook module.
-- Copied all forms.

I'm doing most of the development in Excel 2007, and users are mixed
between Excel 2007 and 2003. On previous projects, I've also seen the
random phantom breakpoint problem on a project done only in Excel
2003.

Any other suggestions?

Thanks,

Greg

A user has now reported the problem while using the workbook on which
I had done the corruption repair.

To test whether the problem was caused by heavy cpu usage per the
other poster, I tried a freeware utility called "Obrut" (turbo spelled
backward), which applies heavy cpu usage and also heavy memory usage.
But even with Obrut on maximum, which slowed my computer down quite a
bit, I still couldn't get a repro.

All of the affected users are on Excel 2007 without service pack, and
the organization has recently approved Office 2007 SP1, so next step
is that we're having affected users install SP1. It may be a few weeks
before we really know whether SP1 helps.

Any other suggestions?

FWIW, here's a download link for Obrut:
http://www.sinnercomputing.com/obrut.htm


Thanks,

Greg


On Feb 12, 8:37 am, Greg Lovern wrote:
Huh??

So you're saying if the CPU is busy, instead of just slowing down,
Excel (a) opens the VBE, and then either (b1) pauses at a line of code
as if at a breakpoint, or (b2) reports that a valid referenced item,
such as a variable, form, built-in Excel function, etc., does not
exist?

I've seen Excel do some crazy things over the years, but that really
takes the cake. Can anyone confirm that hemu is correct?

Or are you (hemu) joking?

Also, what do you mean by "explore through the task bar". Everyone
involved is using Windows XP; how do I "explore" this issue with the
Windows XP taskbar?

No one has yet reported the problem again since I did the workbook
corruption repair tasks yesterday, but I assume everyone's CPU is
probably about as busy as usual.

Greg

On Feb 11, 7:56 pm, Hemant_india

wrote:
it's a problem of cpu usage
explore through task bar
--
hemu

"Greg Lovern" wrote:
We've been getting some strange errors on an Excel VBA project:

On random computers, it stops on random lines as if at a breakpoint,
but there is no breakpoint there; in fact it sometimes happens when a
non-programmer just opens the Excel file and clicks a control to run a
macro. Since VBA doesn't save breakpoints, it obviously isn't a real
breakpoint.

It isn't stopping on an error in those instances, because once it
stops like that, it will happily proceed without error if you simply
press F5.

On the same project, we've also been getting random bogus compile
errors, as if a referenced variable, form, etc. did not exist. Once it
even did it on Excel VBA's built-in Right function, as if Excel VBA's
Right function did not exist. But if we copy the workbook to another
computer, or try again later on the same computer, it runs without
error.

I'm guessing workbook corruption, but is there anything else I should
be looking at too?

Here's what I tried just now:
-- Copied all worksheets to new workbook.
-- Added the required references to the new workbook.
-- For each module and class module, copied text of module into
new module.
-- Copied code behind workbook module.
-- Copied all forms.

I'm doing most of the development in Excel 2007, and users are mixed
between Excel 2007 and 2003. On previous projects, I've also seen the
random phantom breakpoint problem on a project done only in Excel
2003.

Any other suggestions?

Thanks,

Greg

Did you ever find a solution?

I have users across my office expierencing this issue as well.

I have tried the methods you posted above with also no success.



Greg Lovern wrote:

A user has now reported the problem while using the workbook on whichI had
16-Feb-08

A user has now reported the problem while using the workbook on which
I had done the corruption repair.

To test whether the problem was caused by heavy cpu usage per the
other poster, I tried a freeware utility called "Obrut" (turbo spelled
backward), which applies heavy cpu usage and also heavy memory usage.
But even with Obrut on maximum, which slowed my computer down quite a
bit, I still couldn't get a repro.

All of the affected users are on Excel 2007 without service pack, and
the organization has recently approved Office 2007 SP1, so next step
is that we're having affected users install SP1. It may be a few weeks
before we really know whether SP1 helps.

Any other suggestions?

FWIW, here's a download link for Obrut:
http://www.sinnercomputing.com/obrut.htm


Thanks,

Greg


On Feb 12, 8:37 am, Greg Lovern wrote:

Previous Posts In This Thread:

On Monday, February 11, 2008 10:56 PM
Hemantindi wrote:

Random phantom breakpoints and random bogus compile errors
it is a problem of cpu usage
explore through task bar
--
hemu


"Greg Lovern" wrote:

On Tuesday, February 12, 2008 8:27 PM
Greg Lovern wrote:

Random phantom breakpoints and random bogus compile errors
We've been getting some strange errors on an Excel VBA project:

On random computers, it stops on random lines as if at a breakpoint,
but there is no breakpoint there; in fact it sometimes happens when a
non-programmer just opens the Excel file and clicks a control to run a
macro. Since VBA doesn't save breakpoints, it obviously isn't a real
breakpoint.

It isn't stopping on an error in those instances, because once it
stops like that, it will happily proceed without error if you simply
press F5.


On the same project, we've also been getting random bogus compile
errors, as if a referenced variable, form, etc. did not exist. Once it
even did it on Excel VBA's built-in Right function, as if Excel VBA's
Right function did not exist. But if we copy the workbook to another
computer, or try again later on the same computer, it runs without
error.


I'm guessing workbook corruption, but is there anything else I should
be looking at too?

Here's what I tried just now:
-- Copied all worksheets to new workbook.
-- Added the required references to the new workbook.
-- For each module and class module, copied text of module into
new module.
-- Copied code behind workbook module.
-- Copied all forms.

I'm doing most of the development in Excel 2007, and users are mixed
between Excel 2007 and 2003. On previous projects, I've also seen the
random phantom breakpoint problem on a project done only in Excel
2003.

Any other suggestions?


Thanks,

Greg

On Tuesday, February 12, 2008 8:28 PM
Greg Lovern wrote:

Huh??
Huh??

So you're saying if the CPU is busy, instead of just slowing down,
Excel (a) opens the VBE, and then either (b1) pauses at a line of code
as if at a breakpoint, or (b2) reports that a valid referenced item,
such as a variable, form, built-in Excel function, etc., does not
exist?

I've seen Excel do some crazy things over the years, but that really
takes the cake. Can anyone confirm that hemu is correct?

Or are you (hemu) joking?

Also, what do you mean by "explore through the task bar". Everyone
involved is using Windows XP; how do I "explore" this issue with the
Windows XP taskbar?

No one has yet reported the problem again since I did the workbook
corruption repair tasks yesterday, but I assume everyone's CPU is
probably about as busy as usual.

Greg


On Feb 11, 7:56 pm, Hemant_india
wrote:

On Saturday, February 16, 2008 9:28 PM
Greg Lovern wrote:

A user has now reported the problem while using the workbook on whichI had
A user has now reported the problem while using the workbook on which
I had done the corruption repair.

To test whether the problem was caused by heavy cpu usage per the
other poster, I tried a freeware utility called "Obrut" (turbo spelled
backward), which applies heavy cpu usage and also heavy memory usage.
But even with Obrut on maximum, which slowed my computer down quite a
bit, I still couldn't get a repro.

All of the affected users are on Excel 2007 without service pack, and
the organization has recently approved Office 2007 SP1, so next step
is that we're having affected users install SP1. It may be a few weeks
before we really know whether SP1 helps.

Any other suggestions?

FWIW, here's a download link for Obrut:
http://www.sinnercomputing.com/obrut.htm


Thanks,

Greg


On Feb 12, 8:37 am, Greg Lovern wrote:


Submitted via EggHeadCafe - Software Developer Portal of Choice
XAML Organizer
http://www.eggheadcafe.com/tutorials...organizer.aspx

On 02/06/2010 15:20, Daniel Piestrak wrote:
Did you ever find a solution?

I have users across my office expierencing this issue as well.

I have tried the methods you posted above with also no success.

Greg Lovern wrote:

A user has now reported the problem while using the workbook on whichI had
16-Feb-08

A user has now reported the problem while using the workbook on which
I had done the corruption repair.

To test whether the problem was caused by heavy cpu usage per the
other poster, I tried a freeware utility called "Obrut" (turbo spelled
backward), which applies heavy cpu usage and also heavy memory usage.
But even with Obrut on maximum, which slowed my computer down quite a
bit, I still couldn't get a repro.

All of the affected users are on Excel 2007 without service pack, and
the organization has recently approved Office 2007 SP1, so next step
is that we're having affected users install SP1. It may be a few weeks
before we really know whether SP1 helps.

Any other suggestions?

If they are still using XL2007 without sp2 it is amazing they can get
any useful work done at all. The original out of the box version was
unstable wrt race conditions on some multicore machines. Graphics and
charting in combination with VBA would elicit some interesting faults.
Talking here of stable working XL2003 code.

It is still horribly slow at charts and graphics even now and I have a
couple of spreadsheets that use solver and can be killed stone dead by a
too impatient double click on a cell. At least you don't lose any data
but the crashing behaviour in XL2007 is less than ideal.

Regards,
Martin Brown