views:

206

answers:

4

I have a .NET application and a setup fot it. Built using VS 2005.

The development machine is Windows XP SP3.

Once somebody installed it under Windows7. And get the following errors

WinForm ThreadException

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at System.Windows.Forms.UnsafeNativeMethods.IOleObject.DoVerb(Int32 iVerb, IntPtr lpmsg, IOleClientSite pActiveSite, Int32 lindex, IntPtr hwndParent, COMRECT lprcPosRect) at System.Windows.Forms.AxHost.DoVerb(Int32 verb) at System.Windows.Forms.AxHost.InPlaceActivate()

other one

Exception of type 'System.Windows.Forms.AxHost+InvalidActiveXStateException' was thrown. Method 'Disconnect' cannot be invoked at this time.

Now, wondered where was the problem, and installed VS 2005 on this Windows7. Now, the solution compiles and runs without exceptions. I built the setup, and reinstalled the newly built setup on this Win7 machine...

I got the exceptions. Why this?

The applications have no exceptions launched with VS, but throws it when after launching the installed executable...

However, I successfully (without exceptions) tested the installed application on some machines with the OS > Win XP: Windows 7 (x64) and the Windows Server 2008 (x64) ...

Studying the logs, I discovered the code that produces the exception:

Panel p = new Panel();
p.Margin = new Padding(0);
p.Dock = DockStyle.Fill;
p.Controls.Add(display); // 'display' is an ActiveX control instance

Logger.LogMessage("before");

this.tableLayoutPanel.Controls.Add(p); // protected memory EXCEPTION

Logger.LogMessage("after");

So, I see "before" then AccessViolationException: Attempted to read or write protected memory... don't see "after"...

What are the common causes for such an exceptions?

Details

  • I use some third party ActiveX in the application;
  • Samples (written in C++) using that ActiveX runs well on this machine.
  • The solution targets the x86 platform;
  • I managed to launch without errors the application on **Windows Server 2008 (x64) and on Windows 7 (x64);
  • Tried using 'Windows XP Compatibility (SP2, SP3)' mode - the same result (exceptions).
  • Tried to install the application in an other folder that ProgramFiles. I used C:\TestFolder as installation path - the result is the same: AccesViolationException....
+2  A: 

It sounds like you're using an ActiveX control that has compatibility issues with Windows 7.

SLaks
not really. I have a sample using that ActiveX that works well...
serhio
Then it has compatibility issues that show up when you interact with it the way you do in your program.
SLaks
the sample application is written in C++... so probably you have reason... however, I tested my application under other Windows 7... x64 bits... works like a charm.
serhio
updated with some code
serhio
+1  A: 

More than likely you're using an older version of XP that does not have Data Execution Protection. This is enabled by default in Vista and 7, and will cause the exceptions.

You are, most likely, writing to randome pointers, or memory that has already been freed. In other words, you have bugs. Just because it works fine on XP doesn't mean there's nothing wrong with it.

Mystere Man
That's not so likely in .Net.
SLaks
I use XP 2002 SP3, with latest updates installed. I have no "pointers" under .NET 2...
serhio
But your ActiveX controls do.
SLaks
I have a C++ sample using AcX that I managed launcing on that machine.
serhio
updated with some code
serhio
+5  A: 

Wow, an x84 CPU, never seen one of those ;-)) What you mean is probably x64...

Your Windows XP installation is a 64 Bit one ?
It's probably a 32/64-Bit conversion issue, and not a Windows 7 issue.

Forms.UnsafeNativeMethods.IOleObject

Do you pinvoke your ActiveX dll ?

Is it a 32 bit dll or a 64 bit dll ? 32 bit dll's won't run in a 64 bit environment and vice-versa.

If you call it via COM, you might have a chance. But at least on Linux, the C/C++ datatype long has 8 Bytes in 64 bit mode, while it has 4 Bytes in 32 bit mode.

Try targetting the x86 platform (=32 Bit) in the .NET application.

Quandary
Man, don't be so "ironic": The term x86 refers to a family of instruction set architectures based on the Intel 8086 CPU.
serhio
Maybe you didn't attentively read, but the solution **does target** the x84 platform;
serhio
The x84 platform doesn't exist, so you can't target it. The x86-x64 (or in short x64) platform does exist, but anything compiled for x64 won't run on a 32-Bit 80x86 system. But you're right, I didn't attentively read. I first thought you want to run a 32 Bit dll in a 64 Bit process. Whereas you are indeed trying to run a 64 Bit process (or dll) on a 32-Bit machine or process... that of course can't work, and it's certainly not a Windows7 bug. Well, the bug is that it doesn't check the executable/dll for 'bitness'. PEBKAC.
Quandary
@Serhio: And then the 8086 became the 80386, then the 80486, then the 80586, then the 80686, etc. which is why it's written 80x86, to refer to a minimum standard of 80386 backwards compatibility. Then somebody became to lazy to write 80 in front of it, and it became x86, and then somebody became to lazy to write x86 in front of x64. And apparently, some people don't like it, so they create x84 to refer to 80x86-x64.
Quandary
@Quandary: not 84, but 86... my spelling bad... so, it targets **x86** already... this is what I meant.
serhio
@serhio: Ah ok, now it makes sense. But the ActiveX dll is a 64 Bit dll, I take it? Because else it shouldn't have worked in a 64-Bit process? That would explain why it fails when you load/invoke it on a 32 Bit machine, unless you have replaced it with a 32-Bit equivalent.
Quandary
I don't know about AcX, but the application targets x86 platform. I said just that it works on a Windows Server 2008 64 bit system, because we have no an other test system > WinXP (x86).
serhio
When you retarget your project from x64 to x86, and the AcX is an external reference, the AcX will stay a 64 Bit dll. Since it works on x64, I suppose it's a 64 Bit dll. If you can upload it somewhere, I can find that out for ya. Unless your WindowsXP test system where you claim it worked fine is a 32 Bit system.
Quandary
I did't retarget from 64 to 86, before 86 it was "Any CPU", and didn't work on the 64 platforms. But I think there is nothing to do with x64... see my update.
serhio
updated with some code
serhio
A: 

Attach the program to a native debugger and check the stack trace.

You may be having issues with a global hook or extension on that machine that interferes with your COM component.

SLaks
what do you mean... "attach the program to a native debugger"i saw this http://msdn.microsoft.com/en-us/library/k70yt3e2%28VS.80%29.aspx article, but there is so much information... don't understand from where to start
serhio
@serhio: Run Visual Studio and attach its debugger to your program, beng sure to select Native debugging.
SLaks