By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,157 Members | 891 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,157 IT Pros & Developers. It's quick & easy.

BUG: Visual Basic Internal compiler error (related to the known bug)

P: n/a
when attempting to edit code in a class file, i see the bug "Visual Basic
..NET compiler is unable to recover from the following error: System Error
&Hc0000005&(Visual Basic internal compiler error) Save your work and restart
Visual Studio .NET."

has anyone seen this bug and can you confirm one way or the other whether or
not it can corrupt your source files? (by 'corrupt' i mean: do anything to
it that will cause it to fail to load and work properly in VS.Net)

i don't know *exactly* what is the cause of it. it has occurred when i Cut
certain lines out of the code, and also when i delete blank lines. i guess
it is triggered by the background compilation that occurs when you edit
source code.

because the code in question pertains (indirectly) to trying to use
AddHandler/RemoveHandler on a member of an array, i assume this is related
to the known bug discussed here:
http://support.microsoft.com/default...b;en-us;819349

in typically poor M$ documentary fashion, the knowledge base article
mentions not one word of the rest of the story - that this bug can hit you
while you are editing, not just compiling. the background compilation
process is just as susceptible as an explicit compile.

it also doesn't mention one word about a workaround. this seems to go
against M$ documentary practices of obligingly stating (only) the obvious.
i am surprised they couldn't add the one sentence to the KB article:
"Workaround: don't use a control array when you plan to use
AddHandler/RemoveHandler with said controls."

(also note the sentence in the KB article: "Microsoft has confirmed that
this is a bug in the Microsoft products that are listed at the beginning of
this article." Uh ... the products are listed at the end of the article...
it's not a big deal, but it evidences the fact that significant parts of the
M$ help base are totally neglected in terms of revision and editing. come
on guys, intern some grammar school kids or SOMEthing!)

that's about it for now other than to say - thanks M$ for not letting me
down today! another awesome day working with your products, begun the only
*proper* way: being faced with a bug within 5 minutes of booting up the
IDE...

--
-=Where do you want to go today? How about
http://register.microsoft.com/mswish....asp?LCID=1033 ?=-
Jul 21 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
emboldened by a recent backup, i thought i'd continue editing the
problematic (potentially corrupt) source files. *A VERY BAD IDEA!* it
seems the error "Unknown undo/redo error." lurks not far behind... which
can result in operations that fail (like a Cut that doesn't put anything in
the clipboard), yet can't be undone!

sweetness!

i guess now i'll revert to my backup, edit anything potentially offensive
out of the source files using notepad, then try to resume with VS.Net.

(SWEETNESS!)

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:uV**************@tk2msftngp13.phx.gbl...
has anyone seen this bug and can you confirm one way or the other whether or not it can corrupt your source files? (by 'corrupt' i mean: do anything to it that will cause it to fail to load and work properly in VS.Net)

Jul 21 '05 #2

P: n/a
Well, for a start, cut the M$ stuff and start typing like you actually care
about getting a response. Rude posts will get you ignored, nothing more.

Secondly, it seems obvious that the background compilation would fail in
this instance, but you should report it anyway. Maybe they don't know or
havn't realized it fails during background compilation in some\all cases. It
is also very rare to know the exact cause of ICE's, and they are generally
exceedingly rare things.
Also, considering you couldn't get this post grammatically right, stop
fussing so much about other peoples writing.
Now, to suggest a fix, instead of using AddHandler and RemoveHandler
directly on the array, pull each member out into a Control reference and
call it that way. That should work ok.

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:uV****************@tk2msftngp13.phx.gbl...
when attempting to edit code in a class file, i see the bug "Visual Basic
.NET compiler is unable to recover from the following error: System Error
&Hc0000005&(Visual Basic internal compiler error) Save your work and restart Visual Studio .NET."

has anyone seen this bug and can you confirm one way or the other whether or not it can corrupt your source files? (by 'corrupt' i mean: do anything to it that will cause it to fail to load and work properly in VS.Net)

i don't know *exactly* what is the cause of it. it has occurred when i Cut certain lines out of the code, and also when i delete blank lines. i guess it is triggered by the background compilation that occurs when you edit
source code.

because the code in question pertains (indirectly) to trying to use
AddHandler/RemoveHandler on a member of an array, i assume this is related
to the known bug discussed here:
http://support.microsoft.com/default...b;en-us;819349

in typically poor M$ documentary fashion, the knowledge base article
mentions not one word of the rest of the story - that this bug can hit you
while you are editing, not just compiling. the background compilation
process is just as susceptible as an explicit compile.

it also doesn't mention one word about a workaround. this seems to go
against M$ documentary practices of obligingly stating (only) the obvious.
i am surprised they couldn't add the one sentence to the KB article:
"Workaround: don't use a control array when you plan to use
AddHandler/RemoveHandler with said controls."

(also note the sentence in the KB article: "Microsoft has confirmed that
this is a bug in the Microsoft products that are listed at the beginning of this article." Uh ... the products are listed at the end of the article... it's not a big deal, but it evidences the fact that significant parts of the M$ help base are totally neglected in terms of revision and editing. come
on guys, intern some grammar school kids or SOMEthing!)

that's about it for now other than to say - thanks M$ for not letting me
down today! another awesome day working with your products, begun the only *proper* way: being faced with a bug within 5 minutes of booting up the
IDE...

--
-=Where do you want to go today? How about
http://register.microsoft.com/mswish....asp?LCID=1033 ?=-

Jul 21 '05 #3

P: n/a
Well, for a start, cut the M$ stuff and start typing like you actually care
about getting a response. Rude posts will get you ignored, nothing more.

Secondly, it seems obvious that the background compilation would fail in
this instance, but you should report it anyway. Maybe they don't know or
havn't realized it fails during background compilation in some\all cases. It
is also very rare to know the exact cause of ICE's, and they are generally
exceedingly rare things.
Also, considering you couldn't get this post grammatically right, stop
fussing so much about other peoples writing.
Now, to suggest a fix, instead of using AddHandler and RemoveHandler
directly on the array, pull each member out into a Control reference and
call it that way. That should work ok.

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:uV****************@tk2msftngp13.phx.gbl...
when attempting to edit code in a class file, i see the bug "Visual Basic
.NET compiler is unable to recover from the following error: System Error
&Hc0000005&(Visual Basic internal compiler error) Save your work and restart Visual Studio .NET."

has anyone seen this bug and can you confirm one way or the other whether or not it can corrupt your source files? (by 'corrupt' i mean: do anything to it that will cause it to fail to load and work properly in VS.Net)

i don't know *exactly* what is the cause of it. it has occurred when i Cut certain lines out of the code, and also when i delete blank lines. i guess it is triggered by the background compilation that occurs when you edit
source code.

because the code in question pertains (indirectly) to trying to use
AddHandler/RemoveHandler on a member of an array, i assume this is related
to the known bug discussed here:
http://support.microsoft.com/default...b;en-us;819349

in typically poor M$ documentary fashion, the knowledge base article
mentions not one word of the rest of the story - that this bug can hit you
while you are editing, not just compiling. the background compilation
process is just as susceptible as an explicit compile.

it also doesn't mention one word about a workaround. this seems to go
against M$ documentary practices of obligingly stating (only) the obvious.
i am surprised they couldn't add the one sentence to the KB article:
"Workaround: don't use a control array when you plan to use
AddHandler/RemoveHandler with said controls."

(also note the sentence in the KB article: "Microsoft has confirmed that
this is a bug in the Microsoft products that are listed at the beginning of this article." Uh ... the products are listed at the end of the article... it's not a big deal, but it evidences the fact that significant parts of the M$ help base are totally neglected in terms of revision and editing. come
on guys, intern some grammar school kids or SOMEthing!)

that's about it for now other than to say - thanks M$ for not letting me
down today! another awesome day working with your products, begun the only *proper* way: being faced with a bug within 5 minutes of booting up the
IDE...

--
-=Where do you want to go today? How about
http://register.microsoft.com/mswish....asp?LCID=1033 ?=-

Jul 21 '05 #4

P: n/a
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:MrEhb.83238$%h1.86703@sccrnsc02...
Well, for a start, cut the M$ stuff and start typing like you actually care about getting a response. Rude posts will get you ignored, nothing more.
i feel my statements, including my parodized rendition of the common
abbreviation of their company name, are defensible. but that debate belongs
elsewhere... so for now, in the genuine interest of making this NG a more
pleasant place to be, i will 'bite my tongue' and say "my sincere apologies
to anyone who was offended by my rude statement(s)!"*

*Terms and Conditions: Your acknowledgement of this apology signifies your
acceptance of the terms contained herein: 1) This _is_ a sincere apology!
Any attempt to construe it as anything other than such will hereby negate
your entitlement to the benefits it would otherwise confer. 2) Corporations
are not eligible.

=)

Secondly, it seems obvious that the background compilation would fail in
this instance, but you should report it anyway. Maybe they don't know or
havn't realized it fails during background compilation in some\all cases.
all my bug reports are CC'ed to
http://register.microsoft.com/mswish....asp?LCID=1033, but i post on
the NG anyway, since i've heard (and tend to believe) that it takes many
reports of one issue before they deem it 'legitimate' enough to merit
investigation.

i am relatively inexperienced with VS.Net, yet after a quick Google, i was
able to assess that this problem was related to the known bug within about
.... 2 minutes. what legitimate reason could there be for someone who is
intimately familiar with VS.Net (as we presume the members of the VS.Net dev
team to be) to not reach this same realization independently, but even
faster?!

"...they don't know or haven't realized it..." = another way of saying they
spent inadequate time investigating this issue.

which reminds me... i wonder why the bug we are discussing was known in
VS2002 yet still exists in VS2003...

Also, considering you couldn't get this post grammatically right, stop
fussing so much about other peoples writing.
"couldn't" and "didn't" are different things. my NG posts (most of them, at
least) aren't meant to be canon references on technical subjects! they are
informal, and written in an intentionally colloquial style. still, they
usually have no problem being understood.

to contrast: if it was *my (paid) occupation* to write articles for this
newsgroup, they would be unassailable in both content and form, to the best
of my human ability!

either way: maybe i *should* be more conscientious about the bug reports i
write-up, but i still don't think i'm the #1 candidate for "Who Needs To Be
More Conscientious?" here...

and FYI: as for my comment about the grammar school kids: the implication
was not that these kids would be better-qualified for finding obvious errors
and oversights, rather that interns might actually _have the time_ to spend
on 'tedious' tasks like proofreading of documentation. (since the actual
authors and their supervisors/editors evidently don't.)

Now, to suggest a fix, instead of using AddHandler and RemoveHandler
directly on the array, pull each member out into a Control reference and
call it that way. That should work ok.
i *DO* appreciate the suggestion! THANKS! =) ...but forgive me if i don't
try it right away. i already spent a bunch of time rewriting portions of
code back into a form that works, and i just don't have any more time for
experiments with this issue. (especially in dangerous territory like this,
where an entire project can go haywire before you can say "CTRL+Z"!)

maybe on my next project i'll be able to take advantage of this workaround,
but hopefully this bug will be fixed by then and i won't have to!

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:uV****************@tk2msftngp13.phx.gbl...
when attempting to edit code in a class file, i see the bug "Visual Basic .NET compiler is unable to recover from the following error: System Error &Hc0000005&(Visual Basic internal compiler error) Save your work and restart
Visual Studio .NET."

has anyone seen this bug and can you confirm one way or the other whether or
not it can corrupt your source files? (by 'corrupt' i mean: do anything

to
it that will cause it to fail to load and work properly in VS.Net)

i don't know *exactly* what is the cause of it. it has occurred when i

Cut
certain lines out of the code, and also when i delete blank lines. i

guess
it is triggered by the background compilation that occurs when you edit
source code.

because the code in question pertains (indirectly) to trying to use
AddHandler/RemoveHandler on a member of an array, i assume this is

related to the known bug discussed here:
http://support.microsoft.com/default...b;en-us;819349

in typically poor M$ documentary fashion, the knowledge base article
mentions not one word of the rest of the story - that this bug can hit you while you are editing, not just compiling. the background compilation
process is just as susceptible as an explicit compile.

it also doesn't mention one word about a workaround. this seems to go
against M$ documentary practices of obligingly stating (only) the obvious. i am surprised they couldn't add the one sentence to the KB article:
"Workaround: don't use a control array when you plan to use
AddHandler/RemoveHandler with said controls."

(also note the sentence in the KB article: "Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning

of
this article." Uh ... the products are listed at the end of the

article...
it's not a big deal, but it evidences the fact that significant parts of

the
M$ help base are totally neglected in terms of revision and editing. come on guys, intern some grammar school kids or SOMEthing!)

that's about it for now other than to say - thanks M$ for not letting me
down today! another awesome day working with your products, begun the

only
*proper* way: being faced with a bug within 5 minutes of booting up the
IDE...

--
-=Where do you want to go today? How about
http://register.microsoft.com/mswish....asp?LCID=1033 ?=-


Jul 21 '05 #5

P: n/a

"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:uy**************@TK2MSFTNGP11.phx.gbl...
"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:MrEhb.83238$%h1.86703@sccrnsc02...
Well, for a start, cut the M$ stuff and start typing like you actually care
about getting a response. Rude posts will get you ignored, nothing more.


i feel my statements, including my parodized rendition of the common
abbreviation of their company name, are defensible. but that debate

belongs elsewhere... so for now, in the genuine interest of making this NG a more
pleasant place to be, i will 'bite my tongue' and say "my sincere apologies to anyone who was offended by my rude statement(s)!"*

*Terms and Conditions: Your acknowledgement of this apology signifies your acceptance of the terms contained herein: 1) This _is_ a sincere apology!
Any attempt to construe it as anything other than such will hereby negate
your entitlement to the benefits it would otherwise confer. 2) Corporations are not eligible.

=)

Sorry about being cranky, I spend alot of time reading and responding on
these groups and I do expect a level of respect in the posts. Sometimes I
get annoyed at rants.
Secondly, it seems obvious that the background compilation would fail in
this instance, but you should report it anyway. Maybe they don't know or
havn't realized it fails during background compilation in some\all cases.

all my bug reports are CC'ed to
http://register.microsoft.com/mswish....asp?LCID=1033, but i post on the NG anyway, since i've heard (and tend to believe) that it takes many
reports of one issue before they deem it 'legitimate' enough to merit
investigation.

i am relatively inexperienced with VS.Net, yet after a quick Google, i was
able to assess that this problem was related to the known bug within about
... 2 minutes. what legitimate reason could there be for someone who is
intimately familiar with VS.Net (as we presume the members of the VS.Net dev team to be) to not reach this same realization independently, but even
faster?!

"...they don't know or haven't realized it..." = another way of saying they spent inadequate time investigating this issue.

which reminds me... i wonder why the bug we are discussing was known in
VS2002 yet still exists in VS2003...
It got overruled for some reason, would be my guess. In a product of
VS.NET's size, it is very easy for a known bug to slip through the cracks
due to a volume of other bugs & feature additions. Sometimes they just don't
make it in. There is an ICE in C# that I reported during the VS2003 beta
that was never fixed, it simply has to wait because it almost never happens.
It is the unfortunate reality of large, commercial products.
However it is good to send in error reports as often as appropriate and
posting here is not of any real err, it is simply something that I think
should be written a little more calmly. Remember 95% of the readers here do
not and probably never will work for microsoft.
Also, considering you couldn't get this post grammatically right, stop
fussing so much about other peoples writing.
"couldn't" and "didn't" are different things. my NG posts (most of them,

at least) aren't meant to be canon references on technical subjects! they are informal, and written in an intentionally colloquial style. still, they
usually have no problem being understood.

to contrast: if it was *my (paid) occupation* to write articles for this
newsgroup, they would be unassailable in both content and form, to the best of my human ability!

either way: maybe i *should* be more conscientious about the bug reports i write-up, but i still don't think i'm the #1 candidate for "Who Needs To Be More Conscientious?" here...

and FYI: as for my comment about the grammar school kids: the implication was not that these kids would be better-qualified for finding obvious errors and oversights, rather that interns might actually _have the time_ to spend on 'tedious' tasks like proofreading of documentation. (since the actual
authors and their supervisors/editors evidently don't.)
The point was made more because, like I mentioned above, some people spend a
great deal of time reading these groups. A clear, non-ranting post tends to
get a better response than anything else. These people are all here posting
and attempting to help on their own, mostly, not out of any loyalty or paid
occupation.
Now, to suggest a fix, instead of using AddHandler and RemoveHandler
directly on the array, pull each member out into a Control reference and
call it that way. That should work ok.
i *DO* appreciate the suggestion! THANKS! =) ...but forgive me if i

don't try it right away. i already spent a bunch of time rewriting portions of
code back into a form that works, and i just don't have any more time for
experiments with this issue. (especially in dangerous territory like this, where an entire project can go haywire before you can say "CTRL+Z"!)

maybe on my next project i'll be able to take advantage of this workaround, but hopefully this bug will be fixed by then and i won't have to!

Heh, I'm glad the suggestion may work, I don't use VB anywhere near enough
to know if that may cause a problem.
"K. Shier" <ks*****@spamAtYourOwnRisk.yahoo.com> wrote in message
news:uV****************@tk2msftngp13.phx.gbl...
when attempting to edit code in a class file, i see the bug "Visual Basic .NET compiler is unable to recover from the following error: System Error &Hc0000005&(Visual Basic internal compiler error) Save your work and

restart
Visual Studio .NET."

has anyone seen this bug and can you confirm one way or the other whether
or
not it can corrupt your source files? (by 'corrupt' i mean: do anything to
it that will cause it to fail to load and work properly in VS.Net)

i don't know *exactly* what is the cause of it. it has occurred when
i Cut
certain lines out of the code, and also when i delete blank lines. i

guess
it is triggered by the background compilation that occurs when you
edit source code.

because the code in question pertains (indirectly) to trying to use
AddHandler/RemoveHandler on a member of an array, i assume this is

related to the known bug discussed here:
http://support.microsoft.com/default...b;en-us;819349

in typically poor M$ documentary fashion, the knowledge base article
mentions not one word of the rest of the story - that this bug can hit you while you are editing, not just compiling. the background compilation
process is just as susceptible as an explicit compile.

it also doesn't mention one word about a workaround. this seems to go
against M$ documentary practices of obligingly stating (only) the obvious. i am surprised they couldn't add the one sentence to the KB article:
"Workaround: don't use a control array when you plan to use
AddHandler/RemoveHandler with said controls."

(also note the sentence in the KB article: "Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of
this article." Uh ... the products are listed at the end of the

article...
it's not a big deal, but it evidences the fact that significant parts
of
the
M$ help base are totally neglected in terms of revision and editing.

come on guys, intern some grammar school kids or SOMEthing!)

that's about it for now other than to say - thanks M$ for not letting

me down today! another awesome day working with your products, begun the

only
*proper* way: being faced with a bug within 5 minutes of booting up the IDE...

--
-=Where do you want to go today? How about
http://register.microsoft.com/mswish....asp?LCID=1033 ?=-



Jul 21 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.