none
BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress.

    Question

  • Don't know if this is right group to post this question.

    My program is in .Net 2.0,

    It is data entry form that has no code related to graphic manupilation. But my clients sometimes get this error. and it will show some big red X  over some controls.

    I've never seen it in my development machine though.

    "BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress."

    What could cause this problem?

    Thanks

    Thursday, January 12, 2006 2:29 PM

All replies

  • This generally happens when a BufferedGraphicsContext is disposed without been invalidated it.  It looks like this app is using double-buffering, is it handling a previous exception that would let the BufferedGraphicsContext hanging around?

    Monday, January 16, 2006 11:39 PM
  • I've got the same exception.

    Details:

      Message "BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress." string
      StackTrace "   at System.Drawing.BufferedGraphicsContext.Dispose(Boolean disposing)" string

    I'm using DoubleBuffered control style as following:

    Me.SetStyle( _

    ControlStyles.UserPaint _

    Or ControlStyles.DoubleBuffer _

    Or ControlStyles.AllPaintingInWmPaint, _

    True))

     

    Any ideas why?

    Saturday, January 28, 2006 12:14 PM
  • I have the same problem. First i didn't use double buffering. I have an application that displays big images : 1536 x 1200

    Then when i got this error, i made some researches so i endup up to using double buffering. Then it reduces the number of erros (crashes with the same message : buffered graphics cannot be disposed...). It displays this error once an hour....

    It doesn't make this erro on xp, only on win98. THe memory isn't the problem, i have 512 Mo ram. When i had only 256 Mo, it makes this error more often.

     

    I'm gonna try to invalidate the graphics before disposing...

    Wednesday, February 08, 2006 4:09 PM
  • I am a developer of .NET components.  I have recently received a report with the same exception from one of our customers. Have anybody found a solution to this. I do not use anything related to the BufferedGraphicsContext class except for the built-in double buffering:

    SetStyle(ControlStyles.DoubleBuffer, true);

    It looks like a bug in .NET 2.0. Any suggestions?

    Tuesday, August 22, 2006 7:43 AM
  • I have exactly the same problem as the previous author - has no-one found a solution?

    I simply use this.DoubleBuffered = true and then draw away. It never happens on the development machines and generally happens on test computers with quite low system specifications.

    Friday, February 09, 2007 1:28 PM
  • We've now seen this with two customers in the field, both on Windows 98 machines.  I don't believe the OS is necessarily the problem, but the low end hardware probably has someting to do with it!  We're not doing any custom painting using double-buffering ourselves, but we use a number of components (Infragistics, DotNetBar) that certainly do.

    If anyone has any information, it would be extremely helpful and appreciated.

     

    Thursday, February 15, 2007 4:19 AM
  • I'm also having this Problem and i have 2.5GB of RAM .... Before I upgraded my memory form 1.5 on 2.5 application crashed when memory was around 1.4Gb ... now when I have 2.5Gb ,, it crashes at 1.78Gb  ..... I really hope Microsoft will create update if this is a bug,  at least it looks like it......
    Friday, April 06, 2007 2:39 PM
  • This looks like a threading problem to me.  BufferedGraphicsContext is a shared resource for all forms in your app.  Closing a form while another form is busy painting would trip this exception.  It would be a "once in a while" kind of error.  As threading problems always are.

    Be sure to create and show forms only on the UI thread.

    Friday, April 06, 2007 3:29 PM
    Moderator
  • Does anybody from MS have anything to say about this?  I'm seeing this as well, and it may be related to memory usage.  It's not clear. 
    Monday, April 30, 2007 10:43 AM
  • I had the exact same problem, I found out that the problem was that I had set the double buffered control's Width to an invalid value. Perhaps this is not what causes your problems, but it might help you pinpoint it.
    Thursday, June 28, 2007 11:30 AM
  • Does anyone have a consistent repro for this issue? if so, can you report a bug?  thanks,
    Friday, July 06, 2007 12:10 AM
  • i do have faced same type of isssue, firstly on deployment machines but now on development machine as well, i do have 2GB of ram so its not the issue with ram but i have reached to the conclusion that if the process is in paint method, and we call the paint again then this error will come see the code below

     

    pictureBox1.Invalidate();

    pictureBox1.Update();

     

    do write the code in paint method of the picture box i-e calling the repaint in paint.

    Thursday, July 12, 2007 9:53 AM
  • I get the following exception when showing and then removing a user control lots of times:

     

    00117528 00:55:06 [7452] MyApplication_UnhandledException @ 15/07/2007 00:55:05  
    00117529 00:55:06 [7452] System.InvalidOperationException  
    00117530 00:55:06 [7452] BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress.  
    00117531 00:55:06 [7452]    at System.Drawing.BufferedGraphicsContext.Dispose(Boolean disposing)  
    00117532 00:55:06 [7452]    at System.Drawing.BufferedGraphicsContext.Dispose()  
    00117533 00:55:06 [7452]    at System.Drawing.BufferedGraphicsContext.AllocBufferInTempManager(Graphics targetGraphics, IntPtr targetDC, Rectangle targetRectangle)  
    00117534 00:55:06 [7452]    at System.Drawing.BufferedGraphicsContext.Allocate(IntPtr targetDC, Rectangle targetRectangle)  
    00117535 00:55:06 [7452]    at System.Windows.Forms.Control.WmPaint(Message& m)  
    00117536 00:55:06 [7452]    at System.Windows.Forms.Control.WndProc(Message& m)  
    00117537 00:55:06 [7452]    at System.Windows.Forms.ScrollableControl.WndProc(Message& m)  
    00117538 00:55:06 [7452]    at DevComponents.DotNetBar.PanelEx.WndProc(Message& m)  
    00117539 00:55:06 [7452]    at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)  
    00117540 00:55:06 [7452]    at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)  
    00117541 00:55:06 [7452]    at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)  

     

    I have a DotNetBar PanelEx on the user control.  I also feel this could be associated with memory issues as my app was using 1.5GB after running over the weekend and then showing this message towards the end of the test.

     

    Regards, Carl Gilbert

    Monday, July 16, 2007 10:15 AM
  • Has this problem been resolved?

    My boss asked me to resolve it but it seems that it's a bug of .net framework.

    I am wondering if I could re-compile my program on .Net 3.0 to resolve it.

     Wei Wang father of twins wrote:

    Don't know if this is right group to post this question.

    My program is in .Net 2.0,

    It is data entry form that has no code related to graphic manupilation. But my clients sometimes get this error. and it will show some big red X  over some controls.

    I've never seen it in my development machine though.

    "BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress."

    What could cause this problem?

    Thanks

    Friday, August 17, 2007 2:30 PM
  • This indeed seems like a bug in the framework and we at MS haven't been able to identify it since we have not been able to reproduce this problem internally - again, if someone has a consistent repro please report it to us - I don't expect this to be fixed in 3.0 .

    Saturday, August 18, 2007 4:17 AM
  •  Wei Wang father of twins wrote:

    Don't know if this is right group to post this question.

    My program is in .Net 2.0,

    It is data entry form that has no code related to graphic manupilation. But my clients sometimes get this error. and it will show some big red X  over some controls.

    I've never seen it in my development machine though.

    "BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress."

    What could cause this problem?

    Thanks



    Thank u for your reply.  We have a computer which repeat the problem easily which belongs to our test group.  But we can not reproduce it in our development environment.

    Can u give me some suggestion of how to collect information of the bug?  Or can you send someone to come to our place and have a look?  Our company locates in Beijing, China.
    Sunday, August 19, 2007 5:13 AM
  • You can report bugs from this site:  http://lab.msdn.microsoft.com/productfeedback/ - unfortunately we cannot send developers to investigate issues at the customer's place w/o going through support services.

     

    Monday, August 20, 2007 4:58 AM
  • I have a small code sample that can reproduce this exception (on my PC). In the sample it happens because BufferedGraphicsContext can not allocate a back buffer large enough for the control. I create a huge double buffered user control on a small panel and even if only a tiny part of the control is visible on the panel, a back buffer for the full size will get allocated. This can also happen with smaller controls, if the application is using a lot of memory to begin with.

     

    - Peter

     

     

     

     

    using System;

    using System.Collections.Generic;

    using System.ComponentModel;

    using System.Data;

    using System.Drawing;

    using System.Text;

    using System.Windows.Forms;

    namespace UserControlMemoryTest

    {

    public partial class Form1 : Form

    {

    public Form1()

    {

    InitializeComponent();

    }

    class MyUserControl : UserControl

    {

    public MyUserControl()

    {

    SetStyle(ControlStyles.OptimizedDoubleBuffer, true);

    }

    }

    private void button1_Click(object sender, EventArgs e)

    {

    MyUserControl uc = new MyUserControl();

    panel1.Controls.Add(uc);

    uc.Size = new Size(32000, 32000);

    }

    }

    }

    Wednesday, September 05, 2007 4:43 PM
  • Peter,

     

    You said "This can also happen with smaller controls, if the application is using a lot of memory to begin with."  How did you determine this to be true?  Also, can you define "a lot" of memory?  I'm running into this issue along with an OutOfMemory exception and I'm trying to determine if they're related.  Thanks.

    Monday, October 01, 2007 9:47 PM
  • jlento,

     

    My guess is that it happens when the framework runs out of memory, trying to allocate a backbuffer for a control. In my code sample it never had a chance because the control is so huge, but it will happen in any application not leaving enough memory for the back buffer. You are probably running out of virtual memory and/or your virtual memory is fragmented.

     

    Take a look at VM Size in Task Manager. You probably only get the error when it is running high. It's hard to determine exactly how much "high" is, because it doesn't tell you how fragmented the memory is, though.

     

    Try allocating a huge buffer when your app starts (maybe 1GB or more). This should make it easy to get the error consistently - if the above is indeed the case.

     

    - Peter

     

    Tuesday, October 02, 2007 8:48 AM
  • I suppose that you have GDI objects leak. Turn on GDI objects count in Task Manager and whtch the value for your process. I had the same exception, but after I solved GDI objects leakage I never saw it again.

    Tuesday, October 02, 2007 5:29 PM
  • Hi Grish;

     

    I too face this problem and when checked, the GDI objects at one point of time is 9, 997 and then we get the bufferedgraphicscontext error. Pls. let me know how did u resolve the GDI Objects leak issue? This is vague to me. Also, pls. let me know if there are any tutorials for reading and understanding this.

     

    Thanks,

    Bala

    balachandran_srinivasan@hotmail.com

    Monday, October 08, 2007 1:59 PM
  • Unfortunately there is no generic solution. You must review your code (especially painting methods) and check that you're disposing graphics objects such as brushes, pens etc after use. If you have interop code with gdi/user dlls usage - you shall delete objects/device contexts properly to keep GDI objects usage at reasonable level.

     

    I hope this will help.

    Tuesday, October 09, 2007 9:26 PM
  • Thank you very much for pointing to GDI objects count issue. We have the same problem and I've been searching for the reason. First I thought that it was RAM problem. We got the exception (or the application simply crashed) while there was still a lot of RAM available. I can confirm that problem always happens when GDI count reaches 9999. This allowed me to isolate the problem.

    Unfortunately, our application is VS add-in and GDI objects are created by VS when we call some of its methods. So there is no way to solve it for us. I believe, with your info,  MS folks could reproduce and fix it. If it is neccessary, I can try to create VS macro which will reproduce the problem.
    Wednesday, October 10, 2007 2:22 PM
  • I've run some tests and have determined that our GDI count is ballooning upwards because we're using non-default font settings on some of our controls.  Simply changing a font from it's default settting to say bold text causes a new font object to be created which is not Garbage Collected when the form is closed. As a simple test I created a form with 100 textboxes with the font set to it's default settings and repeatedly opened it.  While the GDI count went up a bit with each new form opened, it came back down to its original level once all the forms were closed.  I then set the font to bold for each textbox and repeated the test.  The GDI count increased by more than 100 each time a new form was opened.  Upon closing each form the GDI count barely budged downward.  I experienced the same behavior using the "using" statement at form load to set the font to bold and also manually setting the font to bold at form load and then disposing it at form close.  Not sure why GC will collect everything but the fonts when a form closes.  Eventually GC does collect some of the fonts, but some always remain out there even if all the forms using them are closed and GC'ed themselves.

    Thursday, October 11, 2007 2:33 PM
  • Hi;

     

    Thanks for the posts. I found the reason for the GDI leak but could not fix it in my application. The GDI leaks is due to the objects that are not garbage collected. In my application this is due to Windows menu (MdiWindowListItem).

     

    The scenario is typically like this.

    If i am launching all MDI children from the parent and closing the children and its Parent, then every thing is fine. But

    When launching a MDI child form (say Child 2) from another MDI Child (Say Child 1) of same parent, and closing all the forms including MDI Parent,  the objects are not getting removed from the memory.

     

    But this works fine (No GDI leaks) if Windows menu (MdiWindowListItem) is not there in our MDI form.

     

    Pls. advice if this is a bug or if there are any ways to resolve this.

     

    Thanks,

    Bala

    balachandran_Srinivasan@hotmail.com

     

     

    Sunday, October 14, 2007 10:31 AM
  • Oh, could anyone find a way to avoid this problem?

    I'm almost crazy because of it.  Our application was designed to run for days,  but this problem made out app crush occasionally!

    My boss might fire me for that.
    Sunday, October 14, 2007 1:43 PM
  • Hi ablmf;

     

    Try this. This worked for me.

     

    In the dispose(bool) method of the MDI parent give this code before the existing implementation.

     

    this.toolStripMenuItem1.Dispose(); // MdiWindowListItem = toolStripMenuItem1

     

    /* if you have other toolstripmenuitems attached to the windows menu, dispose them manually */

    this.menuStrip1.Dispose();

     

    for (int i = 0; i <= this.MdiChildren.Length - 1; i++)

    {

    this.MdiChildrenIdea.Dispose();

    }

     

    Thanks,

    Bala

    Monday, October 22, 2007 5:27 PM
  • Hi,

    i was luckily able to reproduce this error in my application.
    I have a selfmade "UserControl". Everytime i set the UserControl.Font to a size larger than 20 this error occurs.
    My Usercontrol is double buffered and userpainted. 
    I worked around it by using my own "MyFont" object instead of using the one from UserControl.
    Taskmanager shows 90 GDI objects when it crashes.
    Hope this can help you to find a solution.

    Regards from Cologne

    Bernd
    Wednesday, November 14, 2007 12:48 PM
  • Hi Balachs,

    Thanks for your help.  But because I am using any MDI forms or any font object in my program,  I don't think any post above could help.

    The situation I am facing is very particular as my application has an ActiveX control in it which is in charge of video decode.  The under ground of the control is ffmpeg, an open source decoder.

    So, now I can not tell if it's bug of the framework or it's beacuse of the ActiveX control.

     Balachs wrote:

    Hi ablmf;

     

    Try this. This worked for me.

     

    In the dispose(bool) method of the MDI parent give this code before the existing implementation.

     

    this.toolStripMenuItem1.Dispose(); // MdiWindowListItem = toolStripMenuItem1

     

    /* if you have other toolstripmenuitems attached to the windows menu, dispose them manually */

    this.menuStrip1.Dispose();

     

    for (int i = 0; i <= this.MdiChildren.Length - 1; i++)

    {

    this.MdiChildren.Dispose();

    }

     

    Thanks,

    Bala

    Monday, November 26, 2007 4:10 PM
  • I am getting the problem using the FileOpenDialog control. We do a lot of our own graphics, but obviously not at that time. The control opens fine, but when I hover the cursor over a file and the control attempts to show the files details, I get the exception. I tried seeing the GDI object count, but when Task Manager is running I can't reproduce the problem.

    Help Please??!?
    Thursday, January 03, 2008 5:42 AM
  • There is bug in Intel graphic driver which might cause GDI leak.

    I'm using that as an excuse for this BufferedGraphicsContext problem but I doubt if it's the real reason.

    Maybe when .net source code is avaliable, we can debug it and see what happend.

     

     Homeopath1 wrote:
    I am getting the problem using the FileOpenDialog control. We do a lot of our own graphics, but obviously not at that time. The control opens fine, but when I hover the cursor over a file and the control attempts to show the files details, I get the exception. I tried seeing the GDI object count, but when Task Manager is running I can't reproduce the problem.

    Help Please??!?

    Thursday, January 03, 2008 2:13 PM
  • Hi all!

    I just finished investigating an issue with the same symptoms as the ones described in this thread.  I found out that the root of the problem is that the OS (GDI) fails to create the DIB that the BufferedGraphicsContext wraps and Winforms throws a Win32Exception from the Win32 error code; the exception message is: "Not enough storage is available to process this command".  This seems to be a problem with the user app, the process is running out of memory or GDI resources.

    However, the framework also has a problem.  It later on throws the exception you are seeing with the message: “BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress” when attempted to be disposed by the framework; this happens because the BGC is not reset after the previous exception occurs. This is very misleading; I will work with my team to get this fixed.

    I hope this helps …

     

    Wednesday, January 09, 2008 7:06 PM
  • One of our customers has seen this problem and I can confirm that it seems to be triggered by an initial out of memory exception (as they see a whole load of those too).

     

    In my case, I tracked the issue down to using Depth32bit on an imagelist which was subsequently set on a (DotNetMagic) tree control to supply its icons.  Whenever the control painted, it would consume VAST amounts of memory (>600MB) in a very short space of time, albeit immedately cleaned up, but that was enough to trigger lots of OutOfMemoryExceptions in other controls.  Using reflector on imagelist, I saw that it uses a different method to obtain a 32bit image, so I tried setting to 16bit mode, and immediately went from >600MB to <1MB memory ramp on painting.  Seems there may be a bug in ImageList when in 32bit mode.

     

    I overrode the tree control paint methods and it was the obtaining of the image from the imagelist that caused the ramping (not the subsequent painting).

    Monday, January 21, 2008 2:11 PM
  • getting recurring buffer over run message when opening internet explorer.

     

    Wednesday, January 30, 2008 2:02 AM

  • I witnessed this today with SQL Server 2005 database engine running.
    Happened when I was trying to connect to a engine with an incorrect name.

    Here is the 'Details' from the error box.
    ====================================== start quote
    See the end of this message for details on invoking
    just-in-time (JIT) debugging instead of this dialog box.

    ************** Exception Text **************
    System.InvalidOperationException: BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress.
       at System.Drawing.BufferedGraphicsContext.Dispose(Boolean disposing)
       at System.Drawing.BufferedGraphicsContext.Dispose()
       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 Microsoft.SqlServer.Management.UI.Grid.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)


    ************** Loaded Assemblies **************
    mscorlib
        Assembly Version: 2.0.0.0
        Win32 Version: 2.0.50727.1433 (REDBITS.050727-1400)
        CodeBase: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
    ----------------------------------------
    AppIDPackage
        Assembly Version: 9.0.242.0
        Win32 Version: 9.00.3042.00
        CodeBase: file:///C:/Program%20Files/Microsoft%20SQL%20Server/90/Tools/Binn/VSShell/Common7/IDE/AppIDPackage.DLL
    ----------------------------------------

    ====================================== end quote

    Hope this helps in your investigation.
    Thanks.
    Tuesday, April 15, 2008 3:09 PM
  • Hi Miguel.

     

    Do you have any news about this problem?

    This problem is making me crazy.

     

    Thanks.

    Thursday, May 29, 2008 12:58 PM
  • I am having the same problem, but with usercontrols not getting destroyed after I dispose of them, and call Container.Controls.Clear. My GDI objects increase to 9999 whereupon I get the BufferedGraphicsContext error and everything crashes.

     

     

     

    Friday, June 13, 2008 3:02 PM
  • Miguell,

     

    Any word on this bug? My interop form dll running on Windows 98 still experiences this problem after having run for some time even though I stripped out of the graphics and the only visual portion is basically a textbox and a button.

     

     

    Wednesday, July 09, 2008 9:55 PM

  • Any update on this issue? Workaround?
    -Is attempting to manually manage the buffered graphics going to make a difference?

    Thank you for your support.
    ++++++++++++++++++++++++++++++++++++++++++++++


    "BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress.":

    Just another basic example to recreate this issue:

    .Net 2.0.

    Create a New Form
    Create a button and dock it at the top
    Add Click event to change the size of the picture box
    Create a label and dock it below the button
    *To display size of picture box
    Create a picture box and change color to something other than system
    Set Autoscroll on the form to true (you dont have to tho)

    Run the app and click the button to size the picture box until you notice something funny with the label..the number stops going up.

    Now try scrolling or moving the form.


    Form1.cs
    ______________________________________________________
    Code Snippet

    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.Data;
    using System.Drawing;
    using System.Text;
    using System.Windows.Forms;

    namespace TestBufferedGraphicsContextErr
    {
    public partial class Form1 : Form
    {
    public Form1()
    {
    InitializeComponent();
    }

    private void button1_Click(object sender, EventArgs e)
    {

    pictureBox1.Size = new Size(pictureBox1.Size.Width + 500, pictureBox1.Size.Height + 500);
    label1.Text = pictureBox1.Size.Width.ToString() + " x " + pictureBox1.Size.Height.ToString();
    }
    }
    }




    Form1.Designer.cs
    Code Snippet


    namespace TestBufferedGraphicsContextErr
    {
    partial class Form1
    {
    /// <summary>
    /// Required designer variable.
    /// </summary>
    private System.ComponentModel.IContainer components = null;

    /// <summary>
    /// Clean up any resources being used.
    /// </summary>
    /// <param name="disposing">true if managed resources should be disposed; otherwise, false.</param>
    protected override void Dispose(bool disposing)
    {
    if (disposing && (components != null))
    {
    components.Dispose();
    }
    base.Dispose(disposing);
    }

    #region Windows Form Designer generated code

    /// <summary>
    /// Required method for Designer support - do not modify
    /// the contents of this method with the code editor.
    /// </summary>
    private void InitializeComponent()
    {
    this.button1 = new System.Windows.Forms.Button();
    this.pictureBox1 = new System.Windows.Forms.PictureBox();
    this.label1 = new System.Windows.Forms.Label();
    ((System.ComponentModel.ISupportInitialize)(this.pictureBox1)).BeginInit();
    this.SuspendLayout();
    //
    // button1
    //
    this.button1.Dock = System.Windows.Forms.DockStyle.Top;
    this.button1.Location = new System.Drawing.Point(0, 0);
    this.button1.Name = "button1";
    this.button1.Size = new System.Drawing.Size(755, 23);
    this.button1.TabIndex = 0;
    this.button1.UseVisualStyleBackColor = true;
    this.button1.Click += new System.EventHandler(this.button1_Click);
    //
    // pictureBox1
    //
    this.pictureBox1.BackColor = System.Drawing.Color.Red;
    this.pictureBox1.Location = new System.Drawing.Point(98, 103);
    this.pictureBox1.Name = "pictureBox1";
    this.pictureBox1.Size = new System.Drawing.Size(155, 124);
    this.pictureBox1.TabIndex = 1;
    this.pictureBox1.TabStop = false;
    //
    // label1
    //
    this.label1.AutoSize = true;
    this.label1.Dock = System.Windows.Forms.DockStyle.Top;
    this.label1.Location = new System.Drawing.Point(0, 23);
    this.label1.Name = "label1";
    this.label1.Size = new System.Drawing.Size(35, 13);
    this.label1.TabIndex = 2;
    this.label1.Text = "label1";
    //
    // Form1
    //
    this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
    this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
    this.AutoScroll = true;
    this.ClientSize = new System.Drawing.Size(755, 585);
    this.Controls.Add(this.label1);
    this.Controls.Add(this.pictureBox1);
    this.Controls.Add(this.button1);
    this.Name = "Form1";
    this.Text = "Form1";
    ((System.ComponentModel.ISupportInitialize)(this.pictureBox1)).EndInit();
    this.ResumeLayout(false);
    this.PerformLayout();

    }

    #endregion

    private System.Windows.Forms.Button button1;
    private System.Windows.Forms.PictureBox pictureBox1;
    private System.Windows.Forms.Label label1;
    }
    }



    Thursday, July 17, 2008 3:37 PM
  •  

    Hi There!

     

    If the problem you are seeing is indeed what we believe as I explained in my previous post then this is fixed in the .net fx SP2 to be released this summer (very soon). 

     

    But observe that what we are fixing is the misleading exception since there is an exception thrown before that renders the buffered graphics invalid. 

     

    The root of the problem is that the OS fails to generate a bitmap for the graphics object possibly because the application (your code) requires an invalid or too-big bitmap to paint the window (the window bounds may be miscalculated for instance).

     

    A potential workaround (that I have not tested) is to override Control.WmPaint to call base.WmPaint within a try/catch block and handle this exception by disabling double buffering just in this case and invalidating the window to force a repaint. What this would do is to paint the window directly when it fails to do double buffering. Please let the community know if this works for you.

     

    Also I believe .net fx SP2 does not support Windows 9x unfortunately.

    Thursday, July 17, 2008 5:55 PM


  • Thanks for responding Miguell.

    How do you override wmPaint for a standard windows control without subclassing though, per the example above?


    Thursday, July 17, 2008 7:17 PM
  • Hi,

     

    I am encoutering the issue without any programing in .Net. For me it seems to be a bug from Excel itself. The first case I saw the problem was with a big workbook with many sheets and especially many graphs containing a lot of points with labels. The second time was in a worbook imported from Excel 2003 with VBA code. As soon as the workbook was loaded, doing nothing else, the GDI object counter started to grow up.

    Hope this help you.

     

    Geth

     

     

    Friday, August 01, 2008 9:37 PM
  •  

    Can you tell me what .NET fx SP2 mean and where will that be available?

     

    Thanks!

    Nitin

    Thursday, August 14, 2008 5:21 PM
  • Hi,

     

    I came across the same problem as described in this thread (my framework version is 3.5).

     

    The exception is being thrown after intensive zoom-in operation (enlarging the control many times).

     

    After looking at this forum thread, I have tried to set control's size to very large (16000 x 16000). It appeard, that now the exception is thrown immediately (application does not start fully).

     

    I would like to ask whether there is limitation in size of control (except the limitation of Integer type) that can be created and if yes, how can be the size limit measured?

     

    Thank you in advance

     

    Tomek.

     

    Thursday, August 14, 2008 8:09 PM
  • I saw an update in the .NET V3.5 SP1 framework code for BufferedGraphics.  It ensures an internal "isbusy" flag is reset when there's an exception.  That is a very good match for "buffer operation is currently in progress" and explains why the problem is hard to reproduce (need an exception at the wrong time).

    Anybody posting to this thread and tried SP1, please confirm that this fix did indeed solve the problem.
    Thursday, August 14, 2008 11:11 PM
    Moderator
  •  

    It sure looks to be memory related, I'm experiencing the same issue .Net 3.5 with a windows form app using my own custom control.  Strangely changing code to reduce memory consumption and using 'peak memory' in Task Manager - I can still get the same exception.

     

    Even stepping over my custom onpaint, the exception can still be thrown but only when I have a large

     

    My code

    Starts with

    a) reads text file

    b) populates a generic DictionaryList

    c) sets up geometry for custom painting

     

    OnPaint I call render passing Graphics object to Render()

    FileOutput calls Render() but it breaks up what's drawn to make it multiple .jpgs

     

    Few hundred objects (lines in CSV) = ok.  Too many = "BufferedGraphicsContext cannot be disposed of because a buffer operation is currently in progress."

     

     

    Putting a 'try/catch' around my Render() didn't help - in fact commenting out the call to Render() and OnPaint.Base I can still raise the error. 

     

    I'm stuck.  The issue seems embeded in the .net core Draw library.

    Wednesday, August 20, 2008 8:49 PM
  •  

    Just a suggestion. Because this have fixed the problem with my application. If you are running windows XP and application uses MFC code than it is worth trying this fix.

    There is a bug in Windows XP SP2 that affects all MFC applications (which includes STATISTICA). The details can be found at MSDN site:

     

    http://support.microsoft.com/default.aspx?scid=kb;en-us;319740

     

    In brief, there is a bug with XP SP2’s handling of desktop themes such that there is GDI resource leak for every window that is created. If you create many windows, you may run up against the 10,000 handle limit. There are two solutions; one is to turn off the XP desktop themes, and the other is to install a Microsoft HotFix. This HotFix is directly available from Microsoft. The MSDN article describes how to obtain this hot fix.

     

    Nitin

     

     

    Wednesday, August 20, 2008 8:54 PM
  • I've installed the hotfix and I'm already not using themes (using 'classic windows') - still get same exception thrown.

     

    Wednesday, August 20, 2008 9:18 PM
  • Hi

    I had the same problem and resovled as follows.

    I use GDIView to displays the list of GDI handles (brushes, pens, fonts, bitmaps, and others) opened by my process. I found that fonts handles's count went double to the count of textbox, combobox, etc. Due to the following code:

    '----- in form main ------
    detail.Show()
    detail.doAfterShow()

    '----- in form detail ------
    Public Overridable Sub doAfterShow()
        AddHandler FormMain().KeyDown, AddressOf Main_KeyDown
        AddHandler FormMain().KeyPress, AddressOf Main_KeyPress
        FirstFocusControl.Focus()
    End Sub


    Problem was cleared by commenting out the 2 lines "AddHandler...".

    I hope this will help.
    • Proposed as answer by bayramakgul Monday, January 19, 2009 12:48 PM
    Thursday, August 21, 2008 9:05 AM
  • BufferedGraphicsContext a = new BufferedGraphicsContext();
                        a.Dispose();

    try this?
    Tuesday, September 23, 2008 4:10 PM
  • hi,  thanks UPRUSH!

    my problem is also resolved!

    i have just used the GDIView and displayed the list of GDI handles. I also found that fonts handles's count increase and increase ... :) 
    Monday, January 19, 2009 12:59 PM
  • listen guys ,

    Even I faced the same problem fews days back, I was getting the same error in my GDI+ application,

    but I solved this problem:

    It happens coz the number of GDI objects in memory exceeds 9999, i.e it reaches 10000, so windows cannot continue processing more GDI objects coz of a certain limit.

    I eventually solved this problem by debugging my code, & checking for what piece of code is increasing GDI objects.

    1. I found that use of CreateGraphics() method is resulting in increasing GDI objects count by 1,
    i.e whenever you use Control.CreateGraphics()   method, it increases GDI Object by 1 in memory

    because this code Control.CreateGraphics()  was in a loop,

    where my code was

    Form f1=new Form();
    Graphics g=f1.CreateGraphics();

    so avoid using .CreateGraphics() method, better use it send as a papameter.


    2. Second thing that I found incrasing load on memory is using DataGridView , so whenever you add a row in  DataGridView, it adds 2 GDI objects in memory.



    Somehow I could minimise GDI objects in memory, but this is not a foolproof solution, because once a GDI object is created It resident in memory, it could result in application shutdown if applicatin is continous running for days.

    I even try to explicity call Garbage Collector , but it does nothing than simply adding a line to my source code.

    so here we need to clear GDI objects from memory, which I am unable to find a better solution.

    Private Limited
    Saturday, August 22, 2009 5:32 AM
  • Hello All,

    I got the same error "BufferedGraphicConxtext" and my problem was resolved after changing Windows Language (In my case was from Spanish to English) and the error was fixed.

    Go to Control Panel
    Click on "Language Configuration"
    Change the language
    Accept

    I hope it works for all like it works to me

    Before doing this I intalled the Framework 2.0 net
    and the hotfix that is in one the post up in this page.

    Regards,
    • Proposed as answer by yyf9989 Friday, December 18, 2009 7:41 AM
    Tuesday, November 03, 2009 7:52 PM
  • I got this same problem in our Antecura Product.  Opening the Page Forms Continuously shown this error "Buffered Graphics context cannot be disposed...". Reported this and solved using same as the BALACH idea here.

    Thanks BALACHs.
    Tuesday, March 02, 2010 6:47 AM