Replies To: The Memory Could Not Be "Written"

Re: The Memory Could Not Be "Written"

Posted 26 December 2012 - 05:55 AM

Without seeing your code, or seeing a callstack, it is impossible to tell what exactly is causing the problem. It would be great if you could post your code, as well as posting the callstack that you get as a result of that exception.

Chances are that you are doing some COM interop and registered a managed class as a callback interface. Later when your program is shutting down, COM is trying to release interfaces and do other cleanup, but your managed code has already freed the memory that COM is trying to use.

Re: The Memory Could Not Be "Written"

Posted 27 December 2012 - 11:18 PM

Skydiver has a great point. Without a call stack it is hard to find a solution for you.

But what i'm assuming you're running across is that it has no callstack information. I've had this problem too, and it didn't use COM interop at all. It was a problem with multi-threading / garbage collection / not checking if things are disposed before I try to close and dispose them.

One of my programs I made has a few panels in a frame. They all do things of various sorts. Some of them kick off a thread to run in the background to catch events of different types. At first it was a rare bug in my program that WIN 7 would say a program crashed and I couldn't figure out why. Then after sometime it happened on a win xp machine. it did keep getting worse and worse until i realized that my panel was being closed and disposed before my objects were being closed and disposed. The worst culprit was my debug window which took the longest to close. long story short I had to make sure that all my variables, objects, and threads were closed and disposed before i closed my panels. Then I disposed of the panels, and lastly I could close my program. See if that doesn't help you out a little.

Re: The Memory Could Not Be "Written"

Posted 28 December 2012 - 07:42 AM

That's a little suspicious. In general, you shouldn't be updating UI across threads specially when working with WinForms. Even if you were successful in crossing threads, the fact that a failure is happening because the panel had closed but your object was still live and sending updates indicates that you didn't correctly setup a reference to the UI. If there was a correct reference setup, the UI may not be visible, but the panel's underlying instance should still be alive and should not cause any crashes when the member variables are updated within it.