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

AccessViolationException: Attempted to read or write protected memory...

P: n/a
Hi,

My C# app throws the following exception:

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

From what I read so far I found that the problem can be connected to P/Invoke and that the places at which this exception is thrown might not reflect the actual problem. In my case, the exception is thrown, when I try to minimise my main window to the system tray and to hide the window from the taskbar:

public void Minimize()
{
this.WindowState = FormWindowState.Minimized;
this.ShowInTaskbar = false; // Exception!
this.Visible = false;
this.exit = true;
}

Here is more detail:

1. I removed all code that deals with P/Invoke, all DLLImports and so on to make sure I am using only fully managed code.

2. I turned off any virus scanner. This could be one possible source of the problem.

3. My configuration is: VS 2005 (SP1 and Vista update), C#, .NET 2, Vista Business.

4. Even though my app contains code to make a web service call, such code will not be called in the scenario that causes the exception. I read that remoting can be a source of the problem.

5. I can reproduce the problem on my machine. Below is a Stack Trace and a Call Stack output. It starts in an OnClosing event that I connect to and then follows a call to the Minimize method before leaping into .NET with ShowInTaskbar (the idea is to cancel the closing of the form in this scenario, to minimize it and to show a tray icon). What I find odd, is the fact that the TreeView Control is involved in the .NET code and that a TreeNode is set in this stack trace. An implementation of TreeView.afterSelect shows that this event will indeed be fired while ShowInTaskbar has been called. I mention this because in the scenario, in which the exception is thrown, I have to expand a few tree node and to send the app to the system tray one or two times until the exception is thrown.

Any idea what could cause the exception?

Thanks and best wishes,

Marc.

Stack Trace from Exception dialog:

" at System.Windows.Forms.UnsafeNativeMethods.CallWindo wProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)\r\n at System.Windows.Forms.NativeWindow.DefWndProc(Messa ge& m)"

Call Stack:

System.Windows.Forms.dll!System.Windows.Forms.Nati veWindow.DefWndProc(ref System.Windows.Forms.Message m = {msg=0x110b hwnd=0x1110704 wparam=0x9
lparam=0x3fb6cf0 result=0x0}) + 0x94 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.DefWndProc(ref System.Windows.Forms.Message m) + 0xc bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.WndProc(ref System.Windows.Forms.Message m) + 0x90b bytes
System.Windows.Forms.dll!System.Windows.Forms.Tree View.WndProc(ref System.Windows.Forms.Message m) + 0xedf bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0xd bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0xd6 bytes
System.Windows.Forms.dll!System.Windows.Forms.Nati veWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 4363, System.IntPtr wparam, System.IntPtr lparam) + 0x75 bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.SendMessage(int msg, int wparam, System.IntPtr lparam) + 0x44 bytes
System.Windows.Forms.dll!System.Windows.Forms.Tree View.SelectedNode.set(System.Windows.Forms.TreeNod e value) + 0x74 bytes
System.Windows.Forms.dll!System.Windows.Forms.Tree View.OnHandleCreated(System.EventArgs e) + 0x331 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.WmCreate(ref System.Windows.Forms.Message m) + 0x40 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.WndProc(ref System.Windows.Forms.Message m) + 0x447 bytes
System.Windows.Forms.dll!System.Windows.Forms.Tree View.WndProc(ref System.Windows.Forms.Message m) + 0xedf bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) + 0xd bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) + 0xd6 bytes
System.Windows.Forms.dll!System.Windows.Forms.Nati veWindow.DebuggableCallback(System.IntPtr hWnd, int msg = 1, System.IntPtr wparam, System.IntPtr lparam) + 0x75 bytes
[Native to Managed Transition]
[Managed to Native Transition]
System.Windows.Forms.dll!System.Windows.Forms.Unsa feNativeMethods.CreateWindowEx(int dwExStyle, string lpszClassName, string lpszWindowName, int style, int
x, int y, int width, int height,
System.Runtime.InteropServices.HandleRef hWndParent,
System.Runtime.InteropServices.HandleRef hMenu,
System.Runtime.InteropServices.HandleRef hInst, object pvParam) + 0x45 bytes
System.Windows.Forms.dll!System.Windows.Forms.Nati veWindow.CreateHandle(System.Windows.Forms.CreateP arams
cp) + 0x241 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.CreateHandle() + 0x16a bytes
System.Windows.Forms.dll!System.Windows.Forms.Tree View.CreateHandle() + 0x6c bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x11b bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.OnParentHandleRecreated() + 0xe4 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x207 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.OnParentHandleRecreated() + 0xe4 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x207 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.OnParentHandleRecreated() + 0xe4 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x207 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.OnParentHandleRecreated() + 0xe4 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x207 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.OnParentHandleRecreated() + 0xe4 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x207 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.OnParentHandleRecreated() + 0xe4 bytes
System.Windows.Forms.dll!System.Windows.Forms.Cont rol.RecreateHandleCore() + 0x207 bytes
System.Windows.Forms.dll!System.Windows.Forms.Form .RecreateHandleCore() + 0x25e bytes
System.Windows.Forms.dll!System.Windows.Forms.Form .ShowInTaskbar.set(bool value) + 0xdc bytes
backup.exe!Adonec.Backup.MainForm.Minimize() Line 392 + 0x9 bytes C#
backup.exe!Adonec.Backup.MainForm.OnClosing(System .ComponentModel.CancelEventArgs e = {System.Windows.Forms.FormClosingEventArgs}) Line 367 + 0x7 bytes C#

Aug 6 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Marc Bartsch schrieb:
Hi,

My C# app throws the following exception:

System.AccessViolationException: Attempted to read or write protected
memory. This is often an indication that other memory is corrupt.

From what I read so far I found that the problem can be connected to
P/Invoke and that the places at which this exception is thrown might not
reflect the actual problem. In my case, the exception is thrown, when I
try to minimise my main window to the system tray and to hide the window
from the taskbar:
After further tests, I found out that disabling Visual Styles in my application seems to get rid of the problem:

[STAThread]
static void Main(string[] args)
{
//Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(fals e);
MainForm mf = new MainForm();

Application.Run(mf);
}

Without visual styles I cannot reproduce the exception anymore. With visual styles, it is reproducable in Debug and Release configuration. This may not be the actual problem and disabling visual styles may only mask the real problem, but this exception seems very hard to track down.

Does anyone know whether visual styles could have something to do with an AccessViolationException?

Best wishes,

Marc.
Aug 7 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.