I am facing the same problem as described here:
Dispatcher throws InvalidOperationException on Messagebox.Show in Textchanged event
Although the solution works for me, I want to solve another problem: When I have no control on whether a message box is shown (external code), how do I gracefully recover from it?
If I set e.Handled = false an exception propagates thought the rest of the code until it is caught somewhere else it making some trivial warning or informational message box mess up the rest of the application.
On the other hand if I set e.Handled = true the dispatcher unhandled exception handler is called over and over again until I press "Ok" in the message box, at which point the application stays "frozen". Pressing pause, this is the call stack:
New: Pressing any key with the (window focused) after closing the MessageBox causes the application to unfreeze and continue execution as normal.
How do I cause the MessageBox to be closed without breaking my application? (even if the messagebox is not shown at all)
EDIT
As requested here is the exception stack trace.
Dispatcher processing has been suspended, but messages are still being processed.
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
More behaviour detected, see "new"
Related
I am developing an 3D app using the Helix3d Toolkit Viewport. The app also communicates with an OPC Server in the background and is continously receiving data. It basically works as it should but when i run it "longer" times like 5-10 days there is a possibility that it suddenly crashes.
The crash may occur when i change from the menu with the 3D Viewport to any other menu. In the menu of the 3D Viewport it continously adds and removes 3D Model to the View based upon the data coming from the OPC Server.
So of course the 3D models will allocate their memory but it basically reaches its maximum when all models are constructed and displayed once. After having a look in the task manager, regarding the used memory, it reaches like 350 MB which is totally okay and it stays there...
But like i said after a run time of 5 days and more it occurs that the program crashes when i simply hide the UserControl containing the 3D view.
In the debugger it says:
{"Insufficient memory to continue the execution of the program."} System.OutOfMemoryException
When this happens the Task Manager displays a value of around 2400 MB used for the app. But i really dont know why, because the 3D display and the server communication runs good for a relatively long time.
What i tried so far:
I installed 16 RAM (8GB before) in the PC...
From my experience so far the error appears not so often anymore...
I gave the app a higher priority in memore allocation with
System.Diagnostics.Process.GetCurrentProcess().PriorityClass = System.Diagnostics.ProcessPriorityClass.High;
but i does not seem to have any effect at all.
I checked my code that it uses no Constructions of any new myClass();
in the methods and program parts which "run continously" so that i basically should not get "more" memory allocation
Before adding or removing a 3D Model i check system ressources
ObjectQuery wql = new ObjectQuery("SELECT * FROM Win32_OperatingSystem");
ManagementObjectSearcher searcher = new ManagementObjectSearcher(wql);
ManagementObjectCollection results = searcher.Get();
But it is not useful because i get the crash when i make a user input like changing a menu.. not while displaying models in 3d...
I switched to 64 Bit
Maybe had the same effect like increasing the RAM...
I would really appreciate if someone could give me a tip how to further locate my problem or maybe what to check exactly. In the background i also write on an MYSQL DB and it also allocates more memory in time but i dont think it has to do something with my original problem...
Concerning the error when it crashes
{"Insufficient memory to continue the execution of the program."} System.OutOfMemoryException
The Strack Trace is:
at System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean enableRenderTarget, Nullable channelSet)
at System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr lParam)
at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
But i really cant figure out something with this.
Thanks for any advice.
Greetings Knally
The background:
I have some model which should give predictions once it is trained. The training has to be done only once - which is rather costly (few seconds). The predictions can then be done very fast.
The training is done implicitely when the first prediction is requested. Because I do not know how many models to be trained at startup time and training all at once is much faster than one by one.
My Problem:
When I am starting my training I am waiting for some tasks to finish. Now Windows is realizing that the UI thread is not busy an more and asking other controls if there is some paint to.
Now some other control also wants a model prediction. In my function I see that the training is not finished and start the training again. Result my function goes crazy - undefined behavior. A lock is of no use here because the second function call is from the same (UI) thread!
What makes it even more iteresting is that this is only an issue in Release mode without Visual Studio attached. So no chance of debugging. Only logging. Took me quite some time to figure out the problem...
Start compiling on thread 1
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at MyComp.MyApp.Model.BestModelEvaluator.Compile()
at MyComp.MyApp.Model.BestModelEvaluator.Evaluate(Double[] in_array)
at MyComp.MyApp.Model.BestModel.ScriptBulkEvaluate(DMyAppionary`2 dMyAppactor, Int32 dicCount)
at MyComp.MyApp.Model.BestModel.BulkEvaluate(DMyAppionary`2 dMyAppactor)
at MyComp.MyApp.Model.MyAppModel.Evaluate(DMyAppionary`2 actuatorValues)
at __Evaluate(MyCompModel* MyComp_model, Int32 regressor_index, uArray<double>* xvalues, uArray<double>* yvalues, uArray<double>* ylower, uArray<double>* yupper, uArray<int>* yvalues_inrange)
at MyCompModel.MakePlot(MyCompModel* , Int32 regressor_index)
at MyAppShell.UpdateCanvasPlots(MyAppShell* , OverlayInfo* ovi, PrintInfo* print_info)
at MyAppShell.UpdateCanvas(MyAppShell* )
at MyAppShell.Notify(MyAppShell* , XMEvent* ev)
at XMWidget.SendEvent(XMWidget* , XMEventType et, XMMailbox* mb, Int32 info, Int32 info1, Int32 info2, Int32 info3)
at XMDrawingArea.DoPaint(XMDrawingArea* , xmRect* rect)
at XMDrawingArea.Message(XMDrawingArea* , MessageType type)
at DrawingAreaWndProc(HWND__* hWnd, UInt32 msg, UInt32 wParam, Int32 lParam)
at CallWindowProcA(IntPtr , HWND__* , UInt32 , UInt32 , Int32 )
at XMDrawingAreaWndProc(HWND__* hWnd, UInt32 msg, UInt32 wParam, Int32 lParam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at ecYaRlzjebO5lJJRJM.eAlVyhEdyCVdmimFqq.koonrpaTJfLI7QASS3()
at ecYaRlzjebO5lJJRJM.eAlVyhEdyCVdmimFqq.e5ChpHZQl(Byte[] )
at ecYaRlzjebO5lJJRJM.eAlVyhEdyCVdmimFqq.GetLicense(LicenseContext , Type , Object , Boolean )
at System.ComponentModel.LicenseManager.ValidateInternalRecursive(LicenseContext context, Type type, Object instance, Boolean allowExceptions, License& license, String& licenseKey)
at System.ComponentModel.LicenseManager.Validate(Type type)
at MyComp.MyApp.Scripting.Script..ctor(String source, ScriptLanguage language)
at MyComp.MyApp.Model.BestEvaluation.BestModelScriptCompiler.PrepareCompilation()
at MyComp.MyApp.Model.BestEvaluation.BestModelScriptCompiler.CompileSynchronous()
at MyComp.MyApp.Model.BestModelEvaluator.Compile()
at MyComp.MyApp.Model.BestModelEvaluator.Evaluate(Double[] in_array)
at MyComp.MyApp.Model.BestModel.Evaluate(DMyAppionary`2 dMyAppactor)
at MyComp.MyApp.Model.MyAppModel.Evaluate(DMyAppionary`2 actuatorValues)
at __Evaluate(MyCompModel* MyComp_model, uArray<double>* xvalues, uArray<double>* yvalues, SByte* comment)
at MyCompModel.MakePredMyAppion(MyCompModel* )
at MyAppShell.UpdateCanvasPlots(MyAppShell* , OverlayInfo* ovi, PrintInfo* print_info)
at MyAppShell.UpdateCanvas(MyAppShell* )
at MyAppShell.Notify(MyAppShell* , XMEvent* ev)
at XMWidget.SendEvent(XMWidget* , XMEventType et)
at MyAppShell.UpdateTree(MyAppShell* )
at MyAppShell.Notify(MyAppShell* , XMEvent* ev)
at XMWidget.SendEvent(XMWidget* , XMEventType et, XMMailbox* mb, Int32 info, Int32 info1, Int32 info2, Int32 info3)
at XMTreeView.SelectItem(XMTreeView* , uTreeNode* item, Int32 send_event)
at XMTreeView.WMessage(XMTreeView* , WidgetMessage msg)
at XMDrawingArea.DoInput(XMDrawingArea* , Void* m, Int32 had_focus)
at XMDrawingArea.Message(XMDrawingArea* , MessageType type)
at DrawingAreaWndProc(HWND__* hWnd, UInt32 msg, UInt32 wParam, Int32 lParam)
at CallWindowProcA(IntPtr , HWND__* , UInt32 , UInt32 , Int32 )
at XMDrawingAreaWndProc(HWND__* hWnd, UInt32 msg, UInt32 wParam, Int32 lParam)
at DispatchMessageA(tagMSG* )
at WinMain(HINSTANCE__* hInstance, HINSTANCE__* hPrevInstance, SByte* lpCmdLine, Int32 nCmdShow)
at _WinMainCRTStartup()
My function is call from an outside application where I have no chance to change that to put the call in background worker.
private bool Compile()
{
lock (compilerLock)
{
if (!isCompiled && CanCompile())
{
CompileSynchronous();
}
}
return isCompiled;
}
I already tried to do the work myself in background and put those calls in Tasks and wait for them. Now my application is waiting for itself forever. Because the second task is waiting for the first to complete. But the first cannot complete because the second is not done - thread and call stack are the same in the end.
I even tried to switch to "blocking" waiting for my task - to no avail...
foreach (Task t in runningTasks)
{
try
{
while (t.IsCompleted == false) ;
//t.Wait();
t.Dispose();
}
catch (Exception ex)
{
// some logging
}
}
I have no idea what else can be done...
EDIT
Running VS 2010 and .net 4.0
EDIT No. 2
To be more clear. My function should block. But it is called twice within the same thread. Even though the first call is not finished. Because it is the same thread locks are no good!
at MyComp.MyApp.Model.BestModelEvaluator.Compile()
...
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageA(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
...
at MyComp.MyApp.Model.BestModelEvaluator.Compile()
Can't you just have the Compile function return the current value of isCompiled if it's called a second time? So instead of blocking to obtain the lock, you try to take the lock, and return the current value of isCompiled if you can't. Like this:
private bool Compile()
{
if (!Monitor.TryEnter(compilerLock))
{
// Lock already taken. There is a compile in progress.
return isCompiled;
}
try
{
if (!isCompiled && CanCompile())
{
CompileSynchronous();
}
return isCompiled;
}
finally
{
Monitor.Exit(compilerLock);
}
}
Edit
I see now that you can't use Monitor because it allows re-entrant calls. You can use Semaphore, though.
private Semaphore CompileSemaphore = new Semaphore(1, 1);
private bool Compile()
{
if (!CompileSemaphore.WaitOne(0))
{
// Lock already taken. There is a compile in progress.
return false;
}
try
{
if (!isCompiled && CanCompile())
{
CompileSynchronous();
}
return isCompiled;
}
finally
{
CompileSemaphore.Releae();
}
}
That will prevent re-entrant calls to CompileSynchronous, which should limit the problems. You can't block the thread on re-entrant calls, because it's the thread that's doing the compile. The best you can hope is that the second call sees the false return and ignores it.
The real problem, though, is that CompileSynchronous re-enters the message loop. That's going to cause you no end of trouble, and there's not much you can do about it except change the program so that can't happen. If you've designed the program so that it calls DoEvents (or otherwise re-enables the message loop), then you've created a huge problem for yourself and you need to re-think your design.
I finally figured out the true problem!
We are encrypting our assemblies with a 3rd party tool. This tool adds a static constructor which is used for some license checking stuff.
Within that code, Application.DoEvents() is called several times which caused all my problems! See (encrypted) Stacktrace:
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at ecYaRlzjebO5lJJRJM.eAlVyhEdyCVdmimFqq.koonrpaTJfLI7QASS3()
Now on startup, I just create a dummy instance of my class. Suddenly all my problems are gone...
Thanks for all your effort!
Okay, then... you have a library.
This is a possible architectural solution to what I understand as your problem:
Decouple calls to your library from calculations your library does
You have to do at least two things to achive that.
Decouple calls to your library from calculation
This can be easily achieved by using a command pattern.
Every time your library gets called, take all information from the call,
put it into one object, and put that object into some (concurrent) queue.
Start a thread to work on that queue, i.e. dequeue object from it and
perform your calculations (this can be on another thread, too).
You can find more information on the command pattern here (as a starter)
Return values from your library
This can be somewhat problematic. At least as you cannot immediately return
a valid result without blocking the UI thread for the first call.
But blocking the UI thread is one of your major problems here.
I would suggest to return a null value at first. On subsequent calls, you
can return the latest result of your calculations.
I would store the latest result of your learning / trained results somewhere
near the UI thread so that you can return immediately after packing things
into the queue described above. The inital / starting value would be a
perfect match for a null-object.
What is gained so far?
Your calculations can be performed indepentently from the UI thread,
you can return instantly and always provide a sane value, and
multiple calls to your library are no longer a problem.
HTH
I am having an issue with a user where my application just throws and unhandled exception for no particular reason. I am not sure what is causing this as the application itself does not check nor handle anything remotely related to and Input Language change event. The exception is pretty vague as it stands with no inner exception or any other information that tells what is going on as it seems to be an arithmetic overflow exception.
Here is the exception message and stack trace:
Type: System.OverflowException
Message: 算術演算の結果オーバーフローが発生しました。
Source: System.Windows.Forms
Stack Trace: 場所 System.Windows.Forms.InputLanguageChangingEventArgs..ctor(InputLanguage inputLanguage, Boolean sysCharSet)
場所 System.Windows.Forms.Control.WmInputLangChangeRequest(Message& m)
場所 System.Windows.Forms.Control.WndProc(Message& m)
場所 System.Windows.Forms.ButtonBase.WndProc(Message& m)
場所 System.Windows.Forms.Button.WndProc(Message& m)
場所 System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
The exception message is "Arithmetic operation resulted in an overflow". Has anyone experienced such behaviour before
This is actually a bug in .NET Framework, in System.Windows.Forms.InputLanguage.Culture getter (you cannot see it in the stack trace since it gets inlined inside InputLanguageChangingEventArgs..ctor by the JIT):
public CultureInfo Culture
{
get
{
return new CultureInfo((int)this.handle & 65535);
}
}
here, this.handle is IntPtr and that means it is 64-bit on x64 OS, but mistakenly casted to int, and that causes the OverflowException if some of the higher bits in this handle are set.
The only workaround I can think of is to completely filter out messages with handle not fitting into int type:
// call this before Application.Run():
Application.AddMessageFilter(new WmInputLangChangeRequestFilter());
class WmInputLangChangeRequestFilter : IMessageFilter
{
public bool PreFilterMessage(ref Message m)
{
if (m.Msg == 0x0050)
{
return (long)m.LParam > 0x7FFFFFFF;
}
return false;
}
}
I have seen the "OverflowException" in Greenshot, where I researched this I arrived here.
Here is some additional information to the issue:
On MSDN there are some comments to it: https://msdn.microsoft.com/en-us/library/windows/desktop/ms632630(v=vs.85).aspx
It is said that the Windows-Message is not posted on e.g. Windows 7, which I can confirm I have never seen it and can't reproduce it.
Here is also some information "WHAT BROKE THE INPUT LANGUAGE MESSAGES?": http://www.siao2.com/2006/05/16/598980.aspx
I currently think that for my application the message is not important, so I added Torvin's solution to ignore it...
I have a WPF application that is crashing on some computers with an AccessViolationException when a drag operation is started.
The difficulty is it is only occurring on builds from our build server, and never crashes when I build locally in Visual Studio 2010. So I cannot step through the code.
I have the following information:
We're using .net 4.0
Only crashes when the application is run as a 64bit process, 32bit is fine.
Only crashes for builds from the build server.
Doesn't crash on every computer, just on a small subset of laptops we have here. Which incidentally are all the same model
and hardware configuration. All have
Windows 7, and some have sp1, some
don't.
What is the next step I should take to diagnose this issue?
Here's the stack trace from the crash, it seems to be occurring in unmanaged code:
at MS.Win32.UnsafeNativeMethods.DoDragDrop(IDataObject dataObject, IOleDropSource dropSource, Int32 allowedEffects, Int32[] finalEffect)
at System.Windows.OleServicesContext.OleDoDragDrop(IDataObject dataObject, IOleDropSource dropSource, Int32 allowedEffects, Int32[] finalEffect)
at System.Windows.DragDrop.OleDoDragDrop(DependencyObject dragSource, DataObject dataObject, DragDropEffects allowedEffects)
at Acquire.Common.UI.Behaviours.DragDropBehaviour.StartDrag(RoutedEventArgs e)
at Acquire.Common.UI.Behaviours.DragDropBehaviour.AttachedElementMouseMove(Object sender, MouseEventArgs e)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
at System.Windows.Input.InputManager.ProcessStagingArea()
at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run()
at Acquire.Mica.Application.App.Main()
Update:
Through trial and error I was able to determine the exact line of code that was causing this crash, and it appears to be perfectly valid. As an experiment I disabled code optimization for the method containing the offending line of code, and the application no longer crashes.
AV exception are the worst, you should be aware that the problem may originate from completely different part in the system.
What normally happens is that you accidently access a memory location that you don't have access to, the program continues to execute as usual, however later on another method tries to access that memory location and causes an error by reading incorrect data place there by mistake.
To debug I suggest that you take advantage of gflags, a tool offered by Microsoft to detect deap corruptions. I used it several times and it saved me hours if not days of debugging effort.
Just a hunch, but since you indicated you are optimizing code, and using a mixed 32/64 bit environment:
Verify the build server a x64 bit environment.
Verify the clients have the proper version .Net environment.
Verify the clients that are running the app are running the right version, ie. 64 bit is only being run by win7 x64 systems and vice versa.
Make sure you clear out the servers temp directories, previous builds in temp directories can cause odd issues such as this.
Also note, the Microsoft developers are idiotic in they way they segregated the two environments, and registry keys / program files etc. are not stored where the program indicates. This was a major stumbling block I had to get past with some apps we created at my company.
Also I belive clipboard & drag+drop calls are STA(Single threaded apratments) calls. The crash could be from a conflict between STA to MTA. Do you have the Main() function decorated with the [STAThread] ?
I personally found this article on 64 bit migration useful: http://www.codeguru.com/cpp/misc/samples/basicprogramming/article.php/c16093/Seven-Steps-of-Migrating-a-Program-to-a-64bit-System.htm
First of all check if all updates are installed on the machines.
Later you could use debugdiag to create a crashdump and check the firstchance and secondchance exceptions to get more info on the matter.
Greetings,
Ian
1st thing I would do is to update the video card driver of those laptops.
at MS.Win32.UnsafeNativeMethods..
This usually means that MS .NET engineer trying to tell you:
"Hey, we didn't write this and it crashed."
Have you guys met something similar?
Exception type: System.ComponentModel.Win32Exception
Exception message: The operation completed successfully .
Exception stack trace:
------------------------
at System.Drawing.BufferedGraphicsContext.CreateCompatibleDIB(IntPtr hdc, IntPtr hpal, Int32 ulWidth, Int32 ulHeight, IntPtr& ppvBits)
at System.Drawing.BufferedGraphicsContext.CreateBuffer(IntPtr src, Int32 offsetX, Int32 offsetY, Int32 width, Int32 height)
at System.Drawing.BufferedGraphicsContext.AllocBuffer(Graphics targetGraphics, IntPtr targetDC, Rectangle targetRectangle)
at System.Drawing.BufferedGraphicsContext.AllocBufferInTempManager(Graphics targetGraphics, IntPtr targetDC, Rectangle targetRectangle)
at System.Drawing.BufferedGraphicsContext.Allocate(IntPtr targetDC, Rectangle targetRectangle)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at DevExpress.XtraEditors.Container.EditorContainer.WndProc(Message& m)
at DevExpress.XtraGrid.GridControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Everywhere in the app where there is one graphics object used , it is used with using so disposing is enabled.
Thanks.
We had some similar problems. It sounds like you have some memory leaks in your application. We also had a similar problem and it took us a long time to find out where and what to fix.
In general I can advice you to check, whether the Dispose method of your win form components get invoked when you hide and don't use it any more. But to verify whether you have memory leaks and where to fix them you need a good memory profiler.
At least in our case it solved these win32 exceptions.
Edit:
I just have seen, that dispose is enabled in your case, I still advice you to check every call! We also thought that Dispose gets called, but sometimes it was not!