Question

For some reason we are getting “InvalidOperationException: Object is currently in use elsewhere.”

during our custom OnPaint, below (that’s actually almost a line for line copy of the code… there’s that little there).

We have logging in the exception handler below to detect if we’re somehow calling OnPaint from a non-UI thread… and that isn’t getting tripped, but we are getting that error logged (see stack trace below).

On machines where we’re getting these errors, we’re also seeing the dreaded Red X of doom from other controls (which presumably don’t have a try/catch around their OnPaints).

They’re probably related, but I can’t figure out what could be causing that error if this code is only called from the UI thread.

Any ideas?

This is the stack trace:

System.InvalidOperationException: Object is currently in use
elsewhere.
at System.Drawing.Graphics.CheckErrorStatus(Int32
status)
at System.Drawing.Graphics.DrawRectangle(Pen pen, Int32
x, Int32 y, Int32 width, Int32 height)
at
System.Windows.Forms.ControlPaint.DrawBorderSimple(Graphics graphics,
Rectangle bounds, Color color, ButtonBorderStyle style)
at
System.Windows.Forms.ControlPaint.DrawBorder(Graphics graphics,
Rectangle bounds, Color color, ButtonBorderStyle style)
at
MyUserControl.OnPaint(PaintEventArgs e)

This is the class:

public class MyUserControl : UserControl
{
    // Override this to set your custom border color
    protected Color mBorderColor = SystemColors.ControlDarkDark;

    public MyeUserControl()
        : base()
    {
        this.BorderStyle = BorderStyle.None;
        this.Padding = new Padding(1);
    }

    protected override void OnPaint(PaintEventArgs e)
    {
        base.OnPaint(e);
        try
        {
            ControlPaint.DrawBorder(e.Graphics, this.ClientRectangle, mBorderColor, ButtonBorderStyle.Solid);
        }
        catch (Exception ex)
        {
            // check if we're not on the UI thread, and if not, log it
            // log exception
        }
    }
}

Answer 1

So, I figured this out some time ago, but forgot to put the answer on here. All the customers with the problem had a single thing in common – they had installed an adobe plugin called FileOpen. It allows users to read encrypted PDFs. Turns out something FileOpen was doing (presumably to block screen captures of encrypted PDFs or something) was interfering with our application, by throwing exceptions during windows GDI+ calls (which get called from .Net OnPaint methods). In working with FileOpen, they whitelisted our application so that they wouldn’t block GDI+ calls from our application.

What made this even more tricky to figure out, is that the blocking only happens after the first time you view an encrypted PDF using FileOpen… so you can have it installed and not experience the problem. If you stop their windows service FileOpenBroker, it also fixes the problem (presumably the service is what is doing the blocking).

Just posting this on here in case anyone else sees the same problem, since this was a huge headache for us at work, and took weeks to figure out.

Update:
There’s a pretty easy workaround, which is to stop FileOpen’s service, which is called FileOpenBroker. You should be able to find it in the list of windows services and as a process in the windows task manager. Once the process has been stopped, it stops whatever they’re doing to screw up GDI+, and then you should be able to use your program until the next time you open an encrypted PDF.

It’s been a while, so I don’t remember for sure, but it’s possible a reboot was necessary to release whatever locks they put in GDI+. I remember I built a batch file to start and stop the service, so that you could use your program without completely disabling the ability to use FileOpen (which I presume is installed because it’s in use on that computer).

I just got contacted by someone else hitting this same problem, so it seems like FileOpen hasn’t fixed the root problem – they only put a band-aid on it by whitelisting our particular application… fair warning.