System.AccessViolation when opening Modal VB6 Form from Hosted VB6 ActiveX control inside .NET WinForms application

[Willy Van den Driessche]

Hi,
i have a rather simple question with a large background. We have a huge existing VB6 application consisting of 100+ VB6 com components. We are rewriting this app in .NET. Since there is more than 30 man years in the existing aplication, we are doing this step by step. In the meantime, the old components are hosted in the new .NET Winforms application. They all behave in a similar way : they show a list of items and have a toolbar on top of it. The grid and the toolbar are activeX controls, hosted on the main screen of the .NET application. All components expose a COM class with a common interface. These classes are instantiated by the .NET application and passed to the grid. The grid displays fine and behaves as planned. However, when the popup menu of the grid is invoked to display a modal (COM) form. Here however things go wrong. On Windows XP the application occasionally hangs. On Windows Vista the application crashes 95% of the time with the exception :


---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()

I can explain for 3 more pages but that's not the idea. We have tried everything. *any* idea is welcome.




__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4794 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Fábio Chicout]

Hi Willy,

Well, I've got this message when my parameters weren't decorated (atributes,
out, in modifiers) correctly.

Post by Willy Van den Driessche
Hi,
i have a rather simple question with a large background. We have a huge
existing VB6 application consisting of 100+ VB6 com components. We are
rewriting this app in .NET. Since there is more than 30 man years in the
existing aplication, we are doing this step by step. In the meantime, the
old components are hosted in the new .NET Winforms application. They all
behave in a similar way : they show a list of items and have a toolbar on
top of it. The grid and the toolbar are activeX controls, hosted on the
main screen of the .NET application. All components expose a COM class
with a common interface. These classes are instantiated by the .NET
application and passed to the grid. The grid displays fine and behaves as
planned. However, when the popup menu of the grid is invoked to display a
modal (COM) form. Here however things go wrong. On Windows XP the
application occasionally hangs. On Windows Vista the application crashes
---> System.AccessViolationException: Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.Uns
afeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
I can explain for 3 more pages but that's not the idea. We have tried
everything. *any* idea is welcome.
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

[Willy Van den Driessche]

Thanks for the reply.

My parameters ought to be decorated correctly since they are all generated
using impLib and aximp.
But maybe these tools made a mistake. I'll check on them again.

Post by Fábio Chicout
Hi Willy,
Well, I've got this message when my parameters weren't decorated (atributes,
out, in modifiers) correctly.

Post by Willy Van den Driessche
Hi,
i have a rather simple question with a large background. We have a huge
existing VB6 application consisting of 100+ VB6 com components. We are
rewriting this app in .NET. Since there is more than 30 man years in the
existing aplication, we are doing this step by step. In the meantime, the
old components are hosted in the new .NET Winforms application. They all
behave in a similar way : they show a list of items and have a toolbar on
top of it. The grid and the toolbar are activeX controls, hosted on the
main screen of the .NET application. All components expose a COM class
with a common interface. These classes are instantiated by the .NET
application and passed to the grid. The grid displays fine and behaves as
planned. However, when the popup menu of the grid is invoked to display a
modal (COM) form. Here however things go wrong. On Windows XP the
application occasionally hangs. On Windows Vista the application crashes
---> System.AccessViolationException: Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.Uns
afeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
I can explain for 3 more pages but that's not the idea. We have tried
everything. *any* idea is welcome.
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4794 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Family Tree Mike]

Hi,
i have a rather simple question with a large background. We have a huge
existing VB6 application consisting of 100+ VB6 com components. We are
rewriting this app in .NET. Since there is more than 30 man years in the
existing aplication, we are doing this step by step. In the meantime,
the old components are hosted in the new .NET Winforms application. They
all behave in a similar way : they show a list of items and have a
toolbar on top of it. The grid and the toolbar are activeX controls,
hosted on the main screen of the .NET application. All components expose
a COM class with a common interface. These classes are instantiated by
the .NET application and passed to the grid. The grid displays fine and
behaves as planned. However, when the popup menu of the grid is invoked
to display a modal (COM) form. Here however things go wrong. On Windows
XP the application occasionally hangs. On Windows Vista the application
---> System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
I can explain for 3 more pages but that's not the idea. We have tried
everything. *any* idea is welcome.
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

I always suspect one of two things in these types of errors:

1. The COM components are built for 32 bit, and you are running 64 bit.
2. Permissions somewhere in the registry finding the components.

You don't say whether the errors happen occasionally/90% on single
machines, or those ratios are "of machines tested". I would build for
x86 (32 bit) first, and retest, since that is the easiest diagnosis.
For the permissions issue, setup a test account with elevated settings
to diagnose.

[Willy Van den Driessche]

Thanks for your reply.

Unfortunately, I cannot see why this would be the case
1) The components are built and run on 32 bit
2) The same components run fine on the exact same machine when run from the
original COM-only host application

Post by Family Tree Mike

Hi,
i have a rather simple question with a large background. We have a huge
existing VB6 application consisting of 100+ VB6 com components. We are
rewriting this app in .NET. Since there is more than 30 man years in the
existing aplication, we are doing this step by step. In the meantime,
the old components are hosted in the new .NET Winforms application. They
all behave in a similar way : they show a list of items and have a
toolbar on top of it. The grid and the toolbar are activeX controls,
hosted on the main screen of the .NET application. All components expose
a COM class with a common interface. These classes are instantiated by
the .NET application and passed to the grid. The grid displays fine and
behaves as planned. However, when the popup menu of the grid is invoked
to display a modal (COM) form. Here however things go wrong. On Windows
XP the application occasionally hangs. On Windows Vista the application
---> System.AccessViolationException: Attempted to read or write
protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32
dwComponentID, Int32 reason, Int32 pvLoopData)
at
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32
reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
I can explain for 3 more pages but that's not the idea. We have tried
everything. *any* idea is welcome.
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

1. The COM components are built for 32 bit, and you are running 64 bit.
2. Permissions somewhere in the registry finding the components.
You don't say whether the errors happen occasionally/90% on single
machines, or those ratios are "of machines tested". I would build for x86
(32 bit) first, and retest, since that is the easiest diagnosis. For the
permissions issue, setup a test account with elevated settings to
diagnose.
--
Mike
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4795 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4795 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Family Tree Mike]

Post by Willy Van den Driessche
Thanks for your reply.
Unfortunately, I cannot see why this would be the case
1) The components are built and run on 32 bit
2) The same components run fine on the exact same machine when run from
the original COM-only host application

Sorry, but I may not have explained my point well.

If the .Net container app is built with "Any CPU", and run on a 64 bit
OS, then the COM components are running in 64 bit mode. This can cause
problems such as what you have reported. I suspect your COM-only host
is built for 32 bit mode.

[Willy Van den Driessche]

I was just saying that we are not ready yet for 64-bit problems (we have
enough in the 32-bit world).
We are running, compiling and testing on 32-bit OS.

Post by Family Tree Mike

Post by Willy Van den Driessche
Thanks for your reply.
Unfortunately, I cannot see why this would be the case
1) The components are built and run on 32 bit
2) The same components run fine on the exact same machine when run from
the original COM-only host application

Sorry, but I may not have explained my point well.
If the .Net container app is built with "Any CPU", and run on a 64 bit OS,
then the COM components are running in 64 bit mode. This can cause
problems such as what you have reported. I suspect your COM-only host is
built for 32 bit mode.
--
Mike
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4795 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4795 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Christian Fröschlin]

Post by Willy Van den Driessche
grid. The grid displays fine and behaves as planned. However, when the
popup menu of the grid is invoked to display a modal (COM) form. Here
however things go wrong.

Do you have access to the source code for the grid and modal form?
If so I'd try to narrow down the problem by removing controls and
code from the form to see if and when the issue goes away.

[Willy Van den Driessche]

Hi, thanks for the reply.

Luckily we have the sources. We have "pinpointed" the problem to the
vsFlexGrid on a user control. If we remove it, the application works.
But ...
If we place the user control *with* the flexgrid directly on our main .NET
screen then the user control *with* the flexgrid works just fine. It's
mind-numbling.
Also, all the COM components work fine (on Windows Vista) when run on a COM
shell. We have replaced the VSFlexGrid (version6) with the latest version
of that commercial control (version 8) and the problem is just the same. To
not exclude any possibility I have sent a mail requesting the PDB files of
these grids (not that I hope they will respond but it doesn't hurt to try).
The only thing that gives us hope right now is that we have so-far been able
to reproduce it pretty consistently on Vista.

Post by Christian Fröschlin

Post by Willy Van den Driessche
grid. The grid displays fine and behaves as planned. However, when the
popup menu of the grid is invoked to display a modal (COM) form. Here
however things go wrong.

Do you have access to the source code for the grid and modal form?
If so I'd try to narrow down the problem by removing controls and
code from the form to see if and when the issue goes away.
__________ Informatie van ESET NOD32 Antivirus, versie van database
viruskenmerken 4796 (20100122) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4796 (20100122) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Erg]

Hello, we are experiencing the exact same problem with the vsFlexGrid. Did you ever resolve the issue?

Thanks.

This is a multi-part message in MIME format.
------=_NextPart_000_000B_01CA9AEA.21983B50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
i have a rather simple question with a large background. We have a huge =
existing VB6 application consisting of 100+ VB6 com components. We are =
rewriting this app in .NET. Since there is more than 30 man years in =
the existing aplication, we are doing this step by step. In the =
meantime, the old components are hosted in the new .NET Winforms =
application. They all behave in a similar way : they show a list of =
items and have a toolbar on top of it. The grid and the toolbar are =
activeX controls, hosted on the main screen of the .NET application. =
All components expose a COM class with a common interface. These =
classes are instantiated by the .NET application and passed to the grid. =
The grid displays fine and behaves as planned. However, when the popup =
menu of the grid is invoked to display a modal (COM) form. Here however =
things go wrong. On Windows XP the application occasionally hangs. On =
Windows Vista the application crashes 95% of the time with the exception =
---> System.AccessViolationException: Attempted to read or write =
protected memory. This is often an indication that other memory is =
corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& =
msg)
at =
System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.Un=
safeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 =
dwComponentID, Int32 reason, Int32 pvLoopData)
at =
System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 =
reason, ApplicationContext context)
at =
System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 =
reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()
I can explain for 3 more pages but that is not the idea. We have tried =
everything. *any* idea is welcome.
__________ Informatie van ESET NOD32 Antivirus, versie van database viruske=
nmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com
------=_NextPart_000_000B_01CA9AEA.21983B50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18865">
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCalibri>Hi,</FONT></DIV>
<DIV><FONT face=3DCalibri>i have a rather simple question with a large=20
background.&nbsp;&nbsp;We have a huge existing VB6 application =
consisting of=20
100+ VB6 com components.&nbsp; We are rewriting this app in .NET.&nbsp; =
Since=20
there is more than 30 man years in the existing aplication, we are doing =
this=20
step by step.&nbsp; In the meantime, the old components are hosted in =
the new=20
.NET Winforms application.&nbsp; They all behave in a similar way : they =
show a=20
list of items and have a toolbar on top of it.&nbsp; The grid and the =
toolbar=20
are activeX controls, hosted on the main screen of the .NET =
application.&nbsp;=20
All components expose a COM class with a common interface.&nbsp; These =
classes=20
are instantiated by the .NET application and passed to the grid.&nbsp; =
The grid=20
displays fine and behaves as planned.&nbsp; However, when the popup menu =
of the=20
grid is invoked to display a modal (COM) form.&nbsp; Here however things =
go=20
wrong.&nbsp; On Windows XP the application occasionally hangs.&nbsp; On =
Windows=20
Vista the application crashes 95% of the time with the exception =
<DIV><FONT size=3D2 face=3DConsolas></FONT>&nbsp;</DIV>

Post by Fábio Chicout
Hi Willy,
Well, I have got this message when my parameters were not decorated (atributes,
out, in modifiers) correctly.

Post by Willy Van den Driessche
Thanks for the reply.
My parameters ought to be decorated correctly since they are all generated
using impLib and aximp.
But maybe these tools made a mistake. I will check on them again.
__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4794 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

Post by Family Tree Mike
1. The COM components are built for 32 bit, and you are running 64 bit.
2. Permissions somewhere in the registry finding the components.
You do not say whether the errors happen occasionally/90% on single
machines, or those ratios are "of machines tested". I would build for
x86 (32 bit) first, and retest, since that is the easiest diagnosis.
For the permissions issue, setup a test account with elevated settings
to diagnose.
--
Mike

Post by Willy Van den Driessche
Thanks for your reply.
Unfortunately, I cannot see why this would be the case
1) The components are built and run on 32 bit
2) The same components run fine on the exact same machine when run from the
original COM-only host application
__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4795 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

Post by Family Tree Mike
Sorry, but I may not have explained my point well.
If the .Net container app is built with "Any CPU", and run on a 64 bit
OS, then the COM components are running in 64 bit mode. This can cause
problems such as what you have reported. I suspect your COM-only host
is built for 32 bit mode.
--
Mike

Post by Willy Van den Driessche
I was just saying that we are not ready yet for 64-bit problems (we have
enough in the 32-bit world).
We are running, compiling and testing on 32-bit OS.
__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4795 (20100121) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com

Post by Christian Fröschlin
Do you have access to the source code for the grid and modal form?
If so I'd try to narrow down the problem by removing controls and
code from the form to see if and when the issue goes away.

Post by Willy Van den Driessche
Hi, thanks for the reply.
Luckily we have the sources. We have "pinpointed" the problem to the
vsFlexGrid on a user control. If we remove it, the application works.
But ...
If we place the user control *with* the flexgrid directly on our main .NET
screen then the user control *with* the flexgrid works just fine. it is
mind-numbling.
Also, all the COM components work fine (on Windows Vista) when run on a COM
shell. We have replaced the VSFlexGrid (version6) with the latest version
of that commercial control (version 8) and the problem is just the same. To
not exclude any possibility I have sent a mail requesting the PDB files of
these grids (not that I hope they will respond but it does not hurt to try).
The only thing that gives us hope right now is that we have so-far been able
to reproduce it pretty consistently on Vista.
__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4796 (20100122) __________
Het bericht is gecontroleerd door ESET NOD32 Antivirus.
http://www.eset.com
Submitted via EggHeadCafe
Client-server autodiscovery in C# and UDP Sockets
http://www.eggheadcafe.com/tutorials/aspnet/9da74d3d-7415-4dfe-984e-2a5db900bdb2/clientserver-autodiscovery-in-c-and-udp-sockets.aspx

[Willy Van den Driessche]

My collegue found the solution. We switched from VS2005 to VS2005 some time ago. We still use the framework 2.0 so we thought everythin would be OK. Everything compiled fine and worked fine (on XP where we developed). However, Microsoft silently changed some LINKER.EXE flags to support windows Vista. The defaults where changed.
The short storyis that we need to "post-edit" our executable to explicitly state :

editbin /NXCOMPAT:NO /TSAWARE:NO outexe.exe

This states that our app is not data-execution-prevention aware and does not fully support terminal services. When setting these two flags, everything works again like a charm. Always.
Thanks a bunch Microsoft ! We sought for this bug with 2 persons for 2 full weeks. I can understand that for the large majority of customers this change of default in the linker goes unnoticed and even makes their application "more compliant". But for us it was all but fun.
"Willy Van den Driessche" <***@hotmail.com> wrote in message news:03AF5CEB-D33A-4588-BD36-***@microsoft.com...
Hi,
i have a rather simple question with a large background. We have a huge existing VB6 application consisting of 100+ VB6 com components. We are rewriting this app in .NET. Since there is more than 30 man years in the existing aplication, we are doing this step by step. In the meantime, the old components are hosted in the new .NET Winforms application. They all behave in a similar way : they show a list of items and have a toolbar on top of it. The grid and the toolbar are activeX controls, hosted on the main screen of the .NET application. All components expose a COM class with a common interface. These classes are instantiated by the .NET application and passed to the grid. The grid displays fine and behaves as planned. However, when the popup menu of the grid is invoked to display a modal (COM) form. Here however things go wrong. On Windows XP the application occasionally hangs. On Windows Vista the application crashes 95% of the time with the exception :


---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()

I can explain for 3 more pages but that's not the idea. We have tried everything. *any* idea is welcome.




__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4794 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com


__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4795 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com



__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4797 (20100122) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Willy Van den Driessche]

The problems has been solved by my colleague but apparently my post got "lost"

My collegue found the solution. We switched from VS2005 to VS2005 some time ago. We still use the framework 2.0 so we thought everythin would be OK. Everything compiled fine and worked fine (on XP where we developed). However, Microsoft silently changed some LINKER.EXE flags to support windows Vista. The defaults where changed.
The short storyis that we need to "post-edit" our executable to explicitly state :

editbin /NXCOMPAT:NO /TSAWARE:NO outexe.exe

This states that our app is not data-execution-prevention aware and does not fully support terminal services. When setting these two flags, everything works again like a charm. Always.
Thanks a bunch Micrsoft ! We sought for this bug with 2 persons for 2 full weeks. I can understand that for the large majority of customers this change of default in the linker goes unnoticed and even makes their application "more compliant". But for us it was all but fun.
"Willy Van den Driessche" <***@hotmail.com> wrote in message news:03AF5CEB-D33A-4588-BD36-***@microsoft.com...
Hi,
i have a rather simple question with a large background. We have a huge existing VB6 application consisting of 100+ VB6 com components. We are rewriting this app in .NET. Since there is more than 30 man years in the existing aplication, we are doing this step by step. In the meantime, the old components are hosted in the new .NET Winforms application. They all behave in a similar way : they show a list of items and have a toolbar on top of it. The grid and the toolbar are activeX controls, hosted on the main screen of the .NET application. All components expose a COM class with a common interface. These classes are instantiated by the .NET application and passed to the grid. The grid displays fine and behaves as planned. However, when the popup menu of the grid is invoked to display a modal (COM) form. Here however things go wrong. On Windows XP the application occasionally hangs. On Windows Vista the application crashes 95% of the time with the exception :


---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.RunDialog(Form form)
at System.Windows.Forms.Form.ShowDialog(IWin32Window owner)
at System.Windows.Forms.Form.ShowDialog()

I can explain for 3 more pages but that's not the idea. We have tried everything. *any* idea is welcome.




__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4794 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com


__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4795 (20100121) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com



__________ Informatie van ESET NOD32 Antivirus, versie van database viruskenmerken 4797 (20100122) __________

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

[Marco]

Friends and friends around the world.
We are presenting the new messenger.
He will be in the commissioning by the friends that we indicate to use the
system.
Access the system by clicking the link below and register free.

You get something for using orkut?
You get something for using skype?
You gain something by using twiter?
You get algumaocisa for using facebook?

Enjoy this is your time!!

Sign up and join for free.


http://www.sqipcom.com/?ref=webempreendedor

http://stakeholder.sqipcom.com/user/webempreendedor