![]() |
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 |
Random phantom breakpoints and random bogus compile errors
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 |
Random phantom breakpoints and random bogus compile errors
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 |
Random phantom breakpoints and random bogus compile errors
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 |
Solved?
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 |
Solved?
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 |
All times are GMT +1. The time now is 01:20 PM. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
ExcelBanter.com