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.DispatchM essageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager. System.Windows.Forms.UnsafeNativeMethods.IMsoCompo nentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.Run MessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.Run MessageLoop(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

Hi Willy,

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

"Willy Van den Driessche" wrote:

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.



"Fábio Chicout" <FbioChicout (AT) discussions (DOT) microsoft.com> wrote


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

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

On 1/21/2010 4:36 PM, Willy Van den Driessche wrote:
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.

--
Mike

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

"Family Tree Mike" <FamilyTreeMike (AT) ThisOldHouse (DOT) com> wrote


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

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

On 1/21/2010 7:49 PM, Willy Van den Driessche wrote:
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

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.

"Family Tree Mike" <FamilyTreeMike (AT) ThisOldHouse (DOT) com> wrote


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

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

Willy Van den Driessche wrote:

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.

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.

"Christian Fröschlin" <froeschlin (AT) mvtec (DOT) com> wrote


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

Het bericht is gecontroleerd door ESET NOD32 Antivirus.

http://www.eset.com

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" <alfredothepistolero (AT) hotmail (DOT) com> wrote

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.DispatchM essageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager. System.Windows.Forms.UnsafeNativeMethods.IMsoCompo nentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.Run MessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.Run MessageLoop(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