Dec 4, 2008 at 9:10 AM
Edited Dec 4, 2008 at 9:12 AM
Ah yes the infamous and cryptic 'Object in use elsewhere'. This exception is a real pain - it stems from the fact that GDI+ is not intended to be used in servers/services as it interacts with the os. Microsofts' Source Servers comments around the offending
/// GDI+ will return a 'generic error' with specific win32 last error codes when
/// a terminal server session has been closed, minimized, etc... We don't want
/// to throw when this happens, so we'll guard against this by looking at the
/// 'last win32 error code' and checking to see if it is either 1) access denied
/// or 2) proc not found and then ignore it.
/// The problem is that when you lock the machine, the secure desktop is enabled and
/// rendering fails which is expected (since the app doesn't have permission to draw
/// on the secure desktop). Not sure if there's anything you can do, short of catching
/// the desktop switch message and absorbing all the exceptions that get thrown while
/// it's the secure desktop.
There doesn't seem to be any solution to this and my experience shows that it gets worse the more cores and processors you throw into the mix. For v2 we are looking into swapping the GDI rendering engine for something different - perhaps AGG.
You *may* be able to ease the pain by experimenting with the user account that the Asp.Net app pool runs in and granting elevated
privileges - 'Interact with Desktop' and probably run as an admin - this is a *massive risk* and you will not be able to do it in a hosted environment. I haven't spent much time doing this and didnt show any signs of
Other things that may help:
Create a new style for each request - do not cache styles in a static variable
If the data doesn't change use a tile cache that way there will hopefully be less contention for what ever the object that is in use elsewhere is - though I am not sure that the error message bears any relation to the error itself