A: 

Had one of these a while back. Our case in point was a PInvoke call: OpenPrinter(string port);

Our issue was that the managed code sent: "LPT1:" but the unmanaged code declared a byte[1024] array and read 1024 bytes onwards from the address of the string. This would read outside of the bounds of the allocated string ("LPT1:") and occasionally wander into memory that wasn't allocated for the application thereby causing this intermittent AccessViolationException.

We fixed this by changing the call to: OpenPrinter(int length, string port) so the unmanaged code could declare a byte array that was the correct length.

This post by ctacke also has some goodies on trying to work out what might be causing this issue.

Quibblesome
Well, my biggest problem is that exception doesn't happen while I am accessing the object explicitly, but when it's accessed from the application's message loop (maybe a repaint or something?) and I presume that in that moment the memory has already been corrupted somehow.
Groo
+1  A: 

It looks very much like a thread safety issue.
I would suggest you start by reading the control's documentation, looking specifically for mention of thread-safety. The threading model typically used by COM components is different - and often incompatible - with (trivial) .NET usage.

AviD
I am using the COM in single threaded apartment, through the mentioned RCW (AxChart). Any calls from the managed Gui thread should be dispatched to the STA message loop automatically (I believe that is what the RCW should do). So threading shouldn't be a problem here.
Groo
You should make sure that either your thread apartment state is set in managed land (TrySetApartmentState) or you have your Main marked up as [STAThread].
Garo Yeriazarian
Yes, STAThread might be helpful here...
AviD
+2  A: 

By adding lots of log traces all over the code, I've managed to notice that in some cases one of the Chart's properties turns into Double.NaN. After I get that, app always crashed during next Chart repaint. By handling the Chart's PrePaint and PostPaint events (luckily it has these events), I confirmed that the crash happens right between these two events.

In particular, it only happens if I set the chart's zoom before it has been painted for the first time (first time since the last update). I managed to do it in a different way, and it hasn't crashed since.

I am not very satisfied with this "solution", since it is obviously some internal problem which cannot be precisely detected before it actually crashes, and I may be only hiding it this way. But I have to leave it as it is for now because I am losing too much time otherwise.

[Update]

Replicated the bug successfully

I did a quick test app, where I set some chart's properties twice, before it is actually painted, and application crashes immediately. I have reported the bug to Software FX, but got no answer. This is not the first irritating bug I am having with this control, but for our next release we're switching to their managed (.Net) version, so we will at least have Reflector to find out how to resolve those bugs.

Anyway thanks everyone!

Groo