VS2005 major development bug

[Edward Diener]

After spending more than a day reducing a complicated compiler bug to a
simple case I reported it to the MSDN Product Feedback Center as a bug
just now. However this bug is completely stymying my development of a
VC++ component. Does Microsoft still offer any free bug reporting cases
for VS2005, as they did two for VS2003 so that I can talk with a
technical representative directly to try to find a workaround for the
compiler bug ?

While I would be normally willing to wait for a response from the bug
report, the magnitude of the bug in my code, where the compiler is
either producing wrong code or the vtable is being destroyed at run-time
by the CLR system, is such that I am dead in the water until the bug is
addressed. While I can continue searching for a workaround for the bug,
for instance by switching from Managed C++ to C++/CLI and see if that
causes any change so that the bug does not occur, if there is none I can
find I must give up creating my code entirely. Therefore I am hoping
that there is some way of addressing the problem directly with Microsoft
without having to pay them directly just to fix their own bad code.

 

[Carl Daniel [VC++ MVP]]

After spending more than a day reducing a complicated compiler bug to
a simple case I reported it to the MSDN Product Feedback Center as a
bug just now. However this bug is completely stymying my development
of a VC++ component. Does Microsoft still offer any free bug
reporting cases for VS2005, as they did two for VS2003 so that I can
talk with a technical representative directly to try to find a
workaround for the compiler bug ?

While I would be normally willing to wait for a response from the bug
report, the magnitude of the bug in my code, where the compiler is
either producing wrong code or the vtable is being destroyed at
run-time by the CLR system, is such that I am dead in the water until
the bug is addressed. While I can continue searching for a workaround
for the bug, for instance by switching from Managed C++ to C++/CLI
and see if that causes any change so that the bug does not occur, if
there is none I can find I must give up creating my code entirely.
Therefore I am hoping that there is some way of addressing the
problem directly with Microsoft without having to pay them directly
just to fix their own bad code.

There's normally no charge for a support incident that's due to a bug in the
product. You may have to pay for a support incident to get things rolling,
but my understanding is that if it's confirmed to be due to a bug, they'll
credit the charge back to you. If you're blocked from proceeding, you
should contact PSS - that's the only way you'll get a hotfix to a current
product. Reporting the bug through the feedback center may get it fixed in
the next release of VC++, but it won't help you in the short term.

If there's a small repro case (it sounds like you did develop one) that you
could post here, perhaps someone can help find a workaround. I'm assuming
that your feedback FDBK48932 is the bug in question - if you could post the
files to the newgroup then we all could take a look.

-cd

 

[Carl Daniel [VC++ MVP]]

I see a number of 1-800-936-5800. Is that the PSS number ? I recall
calling for a number of incidents which were all VC++ bugs for VS2003
.NET but do not remember if that was the number I called. I will
probably wait a little while to see if the bug can at least be
confirmed before going the telephone route as paying Microsoft $245
for my
possible mistake will not be easy on my pocketbook.

Go to http://msdn.microsoft.com/support/, click on "Contact Microsoft" and
find the phone number for your country.

I am hoping it will get me a workaround which is not to taxing on me


I have attached the zip file to this reply which illustrates the bug
in question. I see that I had incorrectly not attached the zip file
to the FDBK48932 report and have now done so. If I am not supposed to
attach a .zip file here to this reply, please tell me which NG I
should use. The explanation for duplicating the bug is on the
FDBK48932 report.

If the bug is my own in some way I will be glad to acknowledge it. I
did spend a great deal of time reducing a very complex case, step by
step,
to try to illustrate the bug in about its simplest format.

Thanks for the repro. I don't have time to look at it this morning, but
I'll spend some time on it this evening.

Thanks for your reply.

You're welcome.

-cd

 

[Andre Kaufmann]

After spending more than a day reducing a complicated compiler bug to a
simple case I reported it to the MSDN Product Feedback Center as a bug
just now.

Which Bug, haven't found one in your example only an access exception ?


Change

private:

File: ValidationEdit.h
Line: 34

into

public:


Then recompile your sample try to run it.


Then retry to run your original sample and look which exception is thrown:

----->>>>>>> System.FieldAccessException


To get detailed information by the compiler define your "pimpl" class
outside the form. As I interpret the pimpl idiom, I would implement it
in a CPP.

[...]

I hope I haven't again misinterpreted your posts again ......... you
remember ...... ? Or done something wrong ?


If I have not misinterpreted your sample, have you another one ?


Andre

 

[Edward Diener]

Which Bug, haven't found one in your example only an access exception ?

When and where ? Did you follow the instructions I gave in my bug report
? If you follow my bug report, when you step into the debugger and try
to trace into "pimpl -> InitializeValidator();", which is line number 46
of ValidationEdit.cpp, you will see in the Disassembly window that it
does not go to that routine but somewhere off of the WndProc routine
instead. This od course causes an exception which is shown in the design
window of the TestValidation project.

Change

private:

File: ValidationEdit.h
Line: 34

into

public:

Line 34 in ValiditionEdit.h is a comment.

/// Required designer variable.

Then recompile your sample try to run it.


Then retry to run your original sample and look which exception is thrown:

----->>>>>>> System.FieldAccessException

No other exception is thrown when I run my code in the debugger except
in the design window specified. It is possible I do not have exception
handling turned on in the debugger but I do not see debugger setting(s)
which controls this. In Tools | Options | Debugging | General is there
an option which controls whether or not an exception is picked up by the
debugger ? Most of my options there are checked.

To get detailed information by the compiler define your "pimpl" class
outside the form. As I interpret the pimpl idiom, I would implement it
in a CPP.

Please do not tell me how to program. The pimpl class is a nested class
of my ref class so that it can access all of the members of my ref class
when it is passed a ref class pointer. In the simple example this is not
an issue but in the more common coding of mixed mode C++ programming
in .NET, this is an easy way for a C++ native class to share code with
its ref class. If it were not a nested class it could only access the
public members of my corresponding ref class when passed a pointer to
that ref class.

I notice that in C++/CLI it is no longer allowed for a native C++ class
to be a nested class of a ref class. Oh brother !!! How does a native
C++ class which contains a good part of the actual functionality of a
ref class now get to call and access protected and private members of
its corresponding ref class in C++/CLI ?

[...]

I hope I haven't again misinterpreted your posts again ......... you
remember ...... ? Or done something wrong ?

I am not getting the exception you mentioned. Your line number is
incorrect. I know how to program and don't need to be told how to use
the pimpl idiom. Other than that I do very much appreciate your help.

 

[Edward Diener]

Go to http://msdn.microsoft.com/support/, click on "Contact Microsoft" and
find the phone number for your country.


Thanks for the repro. I don't have time to look at it this morning, but
I'll spend some time on it this evening.

I have confirmed that, after converting my simple example to an
equivalent C++/CLI sample, everything works perfectly. So this is
clearly a bug somewhere in the Managed C++ code. I had hoped to get my
Managed C++ components to first work under VS2005 and .NET 2.0 before
starting to convert the code to C++/CLI. In my actual code there are
quite a number of far more complicated .NET components than my simple
example shows, as you can imagine, so the best thing to do is just to
work to convert them over. Eventually I will have to do it anyhow so I
might as well just start immediately. Dealing with a Managed C++ bug
such as I have found is just too much of a time waster and I hope, since
C++/CLI is clearly VC++'s future .NET language, I will not run into such
a bad issue again.

 

[Andre Kaufmann]

When and where ? Did you follow the instructions I gave in my bug report

I simply compiled your sample you've attached to a post in this thread
and it crashed.

? If you follow my bug report, when you step into the debugger and try
to trace into "pimpl -> InitializeValidator();", which is line number 46
of ValidationEdit.cpp, you will see in the Disassembly window that it
does not go to that routine but somewhere off of the WndProc routine
instead. This od course causes an exception which is shown in the design
window of the TestValidation project.

Exactly. I haven't debugged the sample into depth, but as I would
interpret it the .NET runtime checks if the embedded class has access to
the outer class, ValidationEdit and as it's forbidden to access private
members from another class (friend declaration don't work also), it
simply throws a security exception.

[...]
----->>>>>>> System.FieldAccessException

No other exception is thrown when I run my code in the debugger except

Your application (attached to your newsgroup post) crashs, with a
failure report stating that an uncaught system access exception has been
thrown. It won't throw that exception if you make the class

Please do not tell me how to program. The pimpl class is a nested class
of my ref class so that it can access all of the members of my ref class

I only mentioned that IMHO a nested class is not the pimpl idiom I read
about in Lakos book, but may be that there are different "pimpl" idioms.
You may name the variable so, but may be somewhat confusing.

I notice that in C++/CLI it is no longer allowed for a native C++ class

It seems that this is also true (now ?) for managed cpp. Don't know if
the compiler should rather throw a compile time error instead of runtime
error.

The sample will also run if you don't access the member variable
initializing directly, but use a public member method:

rClass->IsInitializing()

to be a nested class of a ref class. Oh brother !!! How does a native
C++ class which contains a good part of the actual functionality of a
ref class now get to call and access protected and private members of
its corresponding ref class in C++/CLI ?

[...]

I hope I haven't again misinterpreted your posts again ......... you
remember ...... ? Or done something wrong ?

I am not getting the exception you mentioned. Your line number is
incorrect.

Sorry, must have been moved downwards, because I edited the code
somewhat, checking the access restrictions.

the lines are:

32 private:
33 /// <summary>
34 /// Required designer variable.
35 /// </summary>

If you temporarily change line 32 into public the sample doesn't crash,
at least on my computer / my IDE.

I know how to program and don't need to be told how to use
the pimpl idiom. Other than that I do very much appreciate your help.

You have blamed me not knowing C++ very well too, some months ago.
I'll forget about that from now on, but I couldn't resist to make some
notes about pimpl in my previous post.

And you are using still managed CPP, although you have made such a bad
experience about it, regarding the loader lock. It hasn't directly
something to do with managed CPP itself, but wouldn't it be better to
port to C++/CLI ? Regarding the crash in your sample, C++/CLI seems to
throw a compile time error, while managed cpp silently compiles, but
seems to have the same restrictions (at runtime), as C++/CLI.


As I interpret the problem, the compiler should rather throw a compile
time error, instead of throwing an exception at runtime. So you should
perhaps change your bug report in this regard.

Andre

 

[Edward Diener]

I simply compiled your sample you've attached to a post in this thread
and it crashed.

If you had used the project which was in the .zip file you would have
seen that it was compiled with Managed C++ and not C++/CLI, and that it
compiles fine.

Exactly. I haven't debugged the sample into depth, but as I would
interpret it the .NET runtime checks if the embedded class has access to
the outer class, ValidationEdit and as it's forbidden to access private
members from another class (friend declaration don't work also), it
simply throws a security exception.

No in Managed C++.

[...]
----->>>>>>> System.FieldAccessException

No other exception is thrown when I run my code in the debugger except

Your application (attached to your newsgroup post) crashs, with a
failure report stating that an uncaught system access exception has been
thrown. It won't throw that exception if you make the class

Please do not tell me how to program. The pimpl class is a nested
class of my ref class so that it can access all of the members of my
ref class

I only mentioned that IMHO a nested class is not the pimpl idiom I read
about in Lakos book, but may be that there are different "pimpl" idioms.
You may name the variable so, but may be somewhat confusing.

In normal C++ programming a pimpl class does not have to be a nested
class because one can use the 'friend' declaration to allow the pimpl
class to access all of the members of the other class if necessary.
Because C++ .NET does not allow 'friend', the solution to this in
Managed C++ was to make the pimpl class a nested class of the ref class
and pass a pointer of the ref class to the pimpl class. However even the
ability to have a pimpl nested native class of a ref class has been
taken away in C++/CLI. That is not progress but regress. See my other
post and the only solution I have found for this.

It seems that this is also true (now ?) for managed cpp. Don't know if
the compiler should rather throw a compile time error instead of runtime
error.

The sample will also run if you don't access the member variable
initializing directly, but use a public member method:

rClass->IsInitializing()

While I appreciate your workarounds, my actual code is far more
complicated than my simple sample and the point of posting my bug was to
have someone else ascertain that the bug actually exists on their
machine also. This you did not do because you did not use the
solutions/projects in my zip file. Instead you created your own
solutions/projects, added my source file, then told me what you found.
That is not the way to test someone else's bug.

to be a nested class of a ref class. Oh brother !!! How does a native
C++ class which contains a good part of the actual functionality of a
ref class now get to call and access protected and private members of
its corresponding ref class in C++/CLI ?

[...]


I hope I haven't again misinterpreted your posts again ......... you
remember ...... ? Or done something wrong ?

I am not getting the exception you mentioned. Your line number is
incorrect.

Sorry, must have been moved downwards, because I edited the code
somewhat, checking the access restrictions.

the lines are:

32 private:
33 /// <summary>
34 /// Required designer variable.
35 /// </summary>

If you temporarily change line 32 into public the sample doesn't crash,
at least on my computer / my IDE.

I know how to program and don't need to be told how to use the pimpl
idiom. Other than that I do very much appreciate your help.

You have blamed me not knowing C++ very well too, some months ago.
I'll forget about that from now on, but I couldn't resist to make some
notes about pimpl in my previous post.

And you are using still managed CPP, although you have made such a bad
experience about it, regarding the loader lock. It hasn't directly
something to do with managed CPP itself, but wouldn't it be better to
port to C++/CLI ? Regarding the crash in your sample, C++/CLI seems to
throw a compile time error, while managed cpp silently compiles, but
seems to have the same restrictions (at runtime), as C++/CLI.

I am using Managed C++ because I had a ton of mixed-mode code I
developed for VS2003 in C++, but never ran because of the loader-lock
bug, and I first wanted to move that code to VS2005 and try to build and
run it.

However because of this bug, and the assumption that MS will not be too
interested in fixing bugs in Managed C++ code generation, I am forced to
change my code to use C++/CLI immediately. Changing my sample to use
C++/CLI I see that everything works perfectly.

For me this bug is the final chapter of the Managed C++ fiasco,
including the destructive loader-lock bug in VS2003, other bugs I
reported to MS regarding Managed C++ and VS2003, and now this horrendous
bug with Managed C++ and VS2005. All in all a hideous example of
computer programming by the VC++ team.

I am moving to C++/CLI and hopefully my efforts to use .NET programming
with C++ will now be much better. It could not be worse than it is has
been with Managed C++. I am truly sorry for Microsoft having put out
such bad technology as Managed C++. They are usually a company that does
not make such mistakes.

 

[Jochen Kalmbach [MVP]]

Hi Edward!

For me this bug is the final chapter of the Managed C++ fiasco,

I agree... I also know of other (small) bugs in /clrldsyntax...

But I am also happy that the new syntax is simpler and hopefully
durable... but I also now need to move about 3000 lines of code to
C++/CLI... ;-(

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Andre Kaufmann]

If you had used the project which was in the .zip file you would have
seen that it was compiled with Managed C++ and not C++/CLI, and that it
compiles fine.

The DEBUG configuration compiles fine and then crashs after it is
started. Where did I wrote something about C++/CLI ? Crashing during
compilation would mean then compiler to throw an ICE, but that's surely
not the case.

No in Managed C++.

Yes in managed C++ it compiles rewritten in C++/CLI it compiles not.
That is the main problem. When the managed version is run and the native
object tries to access a private method of the managed object the
runtime throws an System.FieldAccessException.

In normal C++ programming a pimpl class does not have to be a nested

No problem with that.

class because one can use the 'friend' declaration to allow the pimpl
class to access all of the members of the other class if necessary.

I just wondered why you defined the class members in the header. Pimpl,
is commonly used or is designed to decouple objects.
Therefore the class is only declared in the header.

public __gc class ValidationEdit : ......
{
..........
__nogc class ValidationEditPimpl;
};

And defined in the CPP unit. But I don't want to be pedantic and this
has nothing to do with the problem / bug we are discussing in this
thread about.

Because C++ .NET does not allow 'friend', the solution to this in
Managed C++ was to make the pimpl class a nested class of the ref class
and pass a pointer of the ref class to the pimpl class. However even the
ability to have a pimpl nested native class of a ref class has been
taken away in C++/CLI.

And it has been taken away for managed C++ too. Except that it compiles,
but throws a runtime error. While in C++/CLI the compiler, as you wrote,
will throw an error at compilation time.

That is not progress but regress.

It seems that this has nothing to do with C++/CLI itself. But rather
with the code generation / runtime itself. There must have been some
security reasons for this change.

See my other
post and the only solution I have found for this.


While I appreciate your workarounds, my actual code is far more
complicated than my simple sample and the point of posting my bug was to
have someone else ascertain that the bug actually exists on their
machine also. This you did not do because you did not use the
solutions/projects in my zip file.

I did.

Instead you created your own
solutions/projects, added my source file, then told me what you found.
That is not the way to test someone else's bug.

I have not, why should I do so ? You are making assumptions, which you
have in another discussion accused me (always) to do so.

So:

Take your example posted in this newsgroup. Make all private variables
in class ValidationEdit public, as I already wrote, by changing a single
line of code:

File: ValidationEdit.h
Line: 32

private:
/// <summary>
/// Required designer variable.
/// </summary>
System::ComponentModel::Container* components;

into:

public:
/// <summary>
/// Required designer variable.
/// </summary>
System::ComponentModel::Container* components;


Then recompile your control and test it. I did no >>>> other <<<<
changes to your project and I used your project configuration.

I am using Managed C++ because I had a ton of mixed-mode code I
developed for VS2003 in C++, but never ran because of the loader-lock
bug, and I first wanted to move that code to VS2005 and try to build and
run it.

However because of this bug, and the assumption that MS will not be too
interested in fixing bugs in Managed C++ code generation,

IMHO they cannot fix it, because it's a runtime restriction. They could
however throw an error at compilation time.

I am forced to
change my code to use C++/CLI immediately.

IMHO it would be the same in managed C++ if you change your code. But
anyways directly porting to C++/CLI is the better way to go.

Changing my sample to use
C++/CLI I see that everything works perfectly.

For me this bug is the final chapter of the Managed C++ fiasco,
including the destructive loader-lock bug in VS2003, other bugs I
reported to MS regarding Managed C++ and VS2003, and now this horrendous
bug with Managed C++ and VS2005.

The bug is, that the compiler doesn't throw an error at compilation
time. A nested class seems not to be allowed anymore to access private
members of a managed class. This is true for C++/CLI as it's true for
managed C++.

[...]

Andre

 

[Andre Kaufmann]

Jochen Kalmbach [MVP] wrote:

Hi Jochen,

Hi Edward!


I agree... I also know of other (small) bugs in /clrldsyntax...

Please do me a favor. It seems that I and Edward are discussing
cross-purposes.

Take Edwards example and verify that the bug is due to some new (???)
security restrictions.

Take the attached 2 projects in the ZIP file. Compile them and verify
that the project crashs running it outside the IDE (or started without
debugger). Then change a single line of code:

File: ValidationEdit.h
Line: 32

Change:

private:

into:

public:

Recompile the component and then the form and restart it again. It
shouldn't crash anymore.

Please write your results in this thread.
Thank you very much in advance.

But I am also happy that the new syntax is simpler and hopefully
durable... but I also now need to move about 3000 lines of code to
C++/CLI... ;-(

IMHO they should have started with C++/CLI at the beginning. But they
wanted it to make it C++ standard compliant. By using __ double
underscores and not introducing new keywords, without underscores.
Many developers complained about that syntax and what was even worse,
that managed objects couldn't be differentiated from native objects in
template functions and classes.

IMHO now they got it right now, but they are now accused (by C++ ISO
members) having done so. That it's not C++ anymore and that the name
C++/CLI implies it to be so - an advanced C++ standard. And that it's
slowly polluting the C++ standard.

You'll never can make it right for all developers :-/

Andre

 

[Edward Diener]

The DEBUG configuration compiles fine and then crashs after it is
started. Where did I wrote something about C++/CLI ? Crashing during
compilation would mean then compiler to throw an ICE, but that's surely
not the case.



Yes in managed C++ it compiles rewritten in C++/CLI it compiles not.
That is the main problem. When the managed version is run and the native
object tries to access a private method of the managed object the
runtime throws an System.FieldAccessException.

Where does this happen when executing my code example ?

 

[Andre Kaufmann]

Where does this happen when executing my code example ?

Somewhere inside the function call:

pimpl -> InitializeValidator();

I suppose it's the line:

if (!init_val && rClass -> initializing)

if I change this line to:

if (!init_val)

and recompile both solutions everything seems to be OK and a form with
only an edit box is displayed. I suppose this to be the correct behavior
you would expect ?

There seems to be some assembly code before the function's code checking
perhaps if the class may be accessed, but I can't step into it since the
"auto" mode doesn't stop at the line I want to and the native only debug
mode crashs :-(.


Anyway it's a bug and it's a good idea, as you did, to convert managed
C++ code to C++/CLI. Since the compiler then seems to correctly complain
about the problem at compilation time.

Good luck to you, that you won't run into any (such) trouble again.

Andre

 

[Edward Diener]

Somewhere inside the function call:

pimpl -> InitializeValidator();

When I debug the code and this call is made, the code goes to somewhere
after the beginning of the WndProc routine instead. Try going into the
disassembly, when you stop the debugger at the above line, and you will
see this happening. This is exactly what I reported in the bug report.

 

[Andre Kaufmann]

[...]
Where does this happen when executing my code example ?

Somewhere inside the function call:

pimpl -> InitializeValidator();

When I debug the code and this call is made, the code goes to somewhere
after the beginning of the WndProc routine instead.

Not here on my machine. When I try to step into the function call a
System.FieldAccessViolation is thrown, in the Debug configuration.

The Release configuration runs without any problems (???) and doesn't
throw the exception anymore. Seems to be everything O.K. with the
Release. Perhaps another one here in this newsgroup should try to
reproduce my or your behavior, since MS might have the same behavior as
I have and won't address the problem.

Try going into the disassembly, when you stop the debugger
at the above line, and you will
see this happening. This is exactly what I reported
in the bug report.

I can't. Either the exception is thrown directly, when I try to step
into the code (auto mode), or if I switch to native (or managed or
mixed) debugging mode, the debugger stops somewhere in Heap Free.

This behavior might be caused, because an exception (in my case) is
thrown in the Forms constructor and corrupts either the heap, because
some code is dealing with invalid handles / pointers or because the
debugger deals with corrupted data and doesn't show valid results.

Try to encapsulate the function call with a try {} catch(...)

E.g.:

try
{
pimpl -> InitializeValidator();
}
catch(...)
{
System::Windows::Forms::MessageBox::Show("Exception");
}

What happens on your system, when you start the compiled assembly
outside the debugger ?

Andre

 

[Edward Diener]

[...]
Where does this happen when executing my code example ?

Somewhere inside the function call:

pimpl -> InitializeValidator();

When I debug the code and this call is made, the code goes to
somewhere after the beginning of the WndProc routine instead.

Not here on my machine. When I try to step into the function call a
System.FieldAccessViolation is thrown, in the Debug configuration.

The Release configuration runs without any problems (???) and doesn't
throw the exception anymore. Seems to be everything O.K. with the
Release. Perhaps another one here in this newsgroup should try to
reproduce my or your behavior, since MS might have the same behavior as
I have and won't address the problem.

Try going into the disassembly, when you stop the debugger
at the above line, and you will
see this happening. This is exactly what I reported
in the bug report.

I can't. Either the exception is thrown directly, when I try to step
into the code (auto mode), or if I switch to native (or managed or
mixed) debugging mode, the debugger stops somewhere in Heap Free.

I do not understand this "auto mode" or "native mode" or "managed or
mixed" debugging mode. What are these in the IDE ? Is this something I
have to turn on or off from the debugger options ?

When the breakpoint in the code stops at the 'pimpl ->
Initializevalidator() line' why can you not open the Disassembly window
and step through the code there ?

This behavior might be caused, because an exception (in my case) is
thrown in the Forms constructor and corrupts either the heap, because
some code is dealing with invalid handles / pointers or because the
debugger deals with corrupted data and doesn't show valid results.

How do you know that an exception is being thrown in the Forms
constructor if you do not see it when stepping through the code in the
debugger ?

Try to encapsulate the function call with a try {} catch(...)

E.g.:

try
{
pimpl -> InitializeValidator();
}
catch(...)
{
System::Windows::Forms::MessageBox::Show("Exception");
}

What happens on your system, when you start the compiled assembly
outside the debugger ?

This is meaningless since, as I have stated, if the 'pimpl ->
Initializevalidator()' goes to the wrong code completely of course some
exception will be thrown. What I am trying to tell you is what I wrote
in my bug report. If you try to step into 'pimpl ->
Initializevalidator()' you will see that it goes to some place near the
beginning of the WndProc routine. You may be right in what you have
conjectured as the reason this happens, but it is still a bug in the
product, as is any situation where code generation is incorrect.

 

[Andre Kaufmann]

Andre Kaufmann wrote:

I do not understand this "auto mode" or "native mode" or "managed or
mixed" debugging mode. What are these in the IDE ? Is this something I
have to turn on or off from the debugger options ?

It's the setting of the

Project Properties - Configuration Properties - Debugging - Debugger
Type. Where you can select which debugger to start. By default "Auto" is
selected, but sometimes I cannot step into machine code, when debugging
a managed application. I'll then switch to either "Mixed" or "Native
Only" debugger.

When the breakpoint in the code stops at the 'pimpl ->
Initializevalidator() line' why can you not open the Disassembly window
and step through the code there ?

I don't know why I cannot step into the machine code in the disassembly
window, or better said into a "function call". As soon as I try an
exception is thrown or if I use the "Mixed" debugger it executes the
call instruction and stops somewhere in the heap manager with the
following output:

"First-chance exception at 0x7c81eb33 in TestValidation.exe: Microsoft
C++ exception: [rethrow] at memory location 0x00000000.."

With the native debugger I should be able to step into the code anyways,
but it doesn't stop and just after the I've started the debugger it
disables the breakpoint I've set :-((

How do you know that an exception is being thrown in the Forms
constructor if you do not see it when stepping through the code in the
debugger ?

That's my problem, I try to step through the function call, but instead
single stepping the debugger executes all the code I want to step into
and throws the exception.

This is meaningless since, as I have stated, if the 'pimpl ->
Initializevalidator()' goes to the wrong code completely of course some
exception will be thrown.

Perhaps the debugger doesn't work correctly and you get different
results when you run the application without a debugger ? The debugger
may show wrong results too.
Just give it a try.

What I am trying to tell you is what I wrote
in my bug report. If you try to step into 'pimpl ->
Initializevalidator()' you will see that it goes to some place near the
beginning of the WndProc routine.

I only wonder what has the code generation bug to do with if I access a
variable or not or if I make all variables public instead of private ?
If I make all variables public then the same error should occur ? But
it's gone - no exception is thrown and the correct function is called.

You may be right in what you have
conjectured as the reason this happens, but it is still a bug in the
product, as is any situation where code generation is incorrect.

May be I've got different results than you for what reason ever. All I
did is downloading your sample code, compiling and starting it. But
others may have different results too.
Very weird bug.

Andre