Re: Bitmap constructor throwing System.Exception

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Alex Feinman [MVP] (public_news_at_alexfeinman.com)
Date: 06/20/04


Date: Sun, 20 Jun 2004 15:27:27 -0700

Seeing the code is always useful in troubleshooting. This particular problem
however is rather commonly caused by not deallocating *unmanaged* resources.
If you would care to review the Image.Dispose() method internals (appended),
you would see that one thing it does is invoking AG.GL::Destroy on the m_how
which is a pseudo-handle to the unmanaged part of the image. Internally this
handle holds a real handle to a DIB (24 bit - ergo, large) and a DC where
DIB is selected. While you are undoubtedly correct in your explanation of
how GC collects the objects and invokes finalizers, you are wrong on
2 counts. First, disposing the object does not mark it for collection.
Deleting all references to it does. Second, I never said that calling
Dispose will cause he managed memory to be released, nor I implied that the
problem is caused by the lack of managed memory. Most often when loading
large bitmaps, the unmanaged memory into which DIBs are loaded gets
exhausted and causes exceptions when the underlying CreateDIBSection fails
for the lack of memory

Since the scenario I described is by far the most common cause for the error
reported by the OP, I thought that acting on Occam razor principle it might
make sense to try and eliminate it first.

As for the comment on the "filling daily post quota" thing, I'll pretend I
didn't see that.

-- 
Alex Feinman
---
Visit http://www.opennetcf.org
"Rick Winscot" <rickly@zyche dot com> wrote in message
news:ey7UP$vVEHA.264@TK2MSFTNGP10.phx.gbl...
> Alex,
>
> Rather than make guesses... it would be far better to see some code and
> verify what exactly is going on. If you will notice in his original
> description - he mentioned that the emulator worked just fine while a
> 'custom' Win CE 5.0 configuration crashes.
>
> Also - please take a moment to review your information about .net garbage
> collection. Disposing any object merely *marks* it for collection... and
> does not force the garbage collector to spin through unused objects at
> 'your' will. It is recommended to use GC.Collect() to cause the GC to run
> each unused objects finalizer. However, this process is not immediate
> (instantaneous) either... and should be used only when necessary. There is
a
> high amount of probability that this users problem may stem from an err in
> logical approach... which can be easily adjusted for better performance.
It
> is also possible that this problem may be a valid bug with Win CE 5.0. At
> this stage there isn't enough data to make any assumptions.
>
> I know that it is important to fill your daily post quota... but lets take
> discussions in a direction that lead to the best possible answer for each
> individual need. When source is needed... lets wait to see it before
anyone
> invests any time in troubleshooting - in the end, it only wastes your time
> and theirs.
>
> Rick Winscot
> www.zyche.com
>
>
> "Alex Feinman [MVP]" <public_news@alexfeinman.com> wrote in message
> news:%23ezVx$tVEHA.3988@tk2msftngp13.phx.gbl...
> > Are you disposing of the bitmap? By the time GC gets around to freeing
the
> > object it might be too late for your app, so once you are done with the
> > bitmap, don't forget to invoke .Dispose on it
> >
> > -- 
> > Alex Feinman
> > ---
> > Visit http://www.opennetcf.org
> > <ongg@w-linknospam.net> wrote in message
> > news:eJZgfHoVEHA.3988@tk2msftngp13.phx.gbl...
> > > I have an app that does a new Bitmap(filename);  The filename exists
for
> > > sure.
> > >
> > > I ran this from Visual Studio .Net 2003 in the emulator, and it works
> > fine.
> > > However, when I run this on a custom Windows CE 5.0 configuration , I
> > > sometimes get a System.Exception.
> > >
> > > It has nothing to do with the file.. It seems like maybe after a
certain
> > > number of times of loading a bitmap, I get this error. (although that
> may
> > > not be it).
> > >
> > > Has anyone seen this?  It's a generic System.Exception, not a derived
> > class
> > > (at least according to the Message property).
> > >
> > > Thanks!
> > > Jay
> > >
> > >
> >
> >
>
>