Trouble of GDI+ generic error!

[James Wong]

Hi everybody,

I'm facing a serious trouble relating to GDI+ generic error. The error
message is "A Generic error occured in GDI+" and the following information
is stored in Excepton object:
System.Drawing. Graphics.CheckE rrorStatus(Int3 2 status)
System.Drawing. Graphics.DrawSt ring(String s, Font font, Brush brush,
RectangleF layoutRectangle , StringFormat format)
System.Drawing. Graphics.DrawSt ring(String s, Font font, Brush brush,
PointF point, StringFormat format)

In my application, I use DrawString to print text on printer. This is a POS
application in retail store and one receipt is printed every minute in rush
hours. The symptom reported by user is the program stop response or no
receipt is printed after 3 or 4 hours operation during rush hours. The
above error message is logged by my appliction. After reboot the machine,
it works normally again for another few hours.

I suspect the problem is caused by memory corruption but no idea how to
trace to source. The suspects are:
1. my code
2. GDI+ / .NET Framework
3. hardware (e.g. insufficient RAM)

I've also tried to add some GC.Collect() code in my code but there's no
improvement at all.

Here is the hardware / software configuration to run my application:
1. Intel Celeron 2G with 512MB
2. Star TSP 700 printer
3. Windows XP Professional with SP2 and latest patches
4. .NET Framework 2.0
5. SQL Server 2000 Desktop Edition with latest patches
6. Application compiled by VB.NET 2005

Would anybody have any idea how I can trace the source of this problem?
Thanks a lot for your attention and kindly advice!

Regards,
James Wong

[Steven Cheng[MSFT]]

Hi James,

From your description, you're encountering the following error:

"A Generic error occured in GDI+......."

in a winform application which print outo some string data into printer,
correct?

As for the "A Generic error occured in GDI+", it does be a very generic
exception that will sometimes occur in graphics application. I'm not sure
whether your applciation's code logic is very complex and contains many
other codelogic (not related to the GDI+ printing)? if so, I would suggest
you try creating a simplified project that dedicate the GDI+ processing to
see whether you can reproduce the issue.

For memory specific issue, a commom diagnostic means is using the
performance counter(process memory) to montior the managed and unmanaged
memory usage of your application's running process. You can check whether
there is particular memory pressure(at unmanaged or managed memory ...).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

=============== =============== =============== =====

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no rights.

[James Wong]

Hi Steven,

Thanks for your response!

Yes, I got this error while printing something to printer in WinForm
application. However, this problem does not occurs everytime when I print,
so it's not easy to reproduce. What I can ensure is that if the program
runs for 3 or 4 hours (maybe around 200+ receipts are printed), this problem
may happen. After restarting the program (no need to reboot), it resumes to
normal for another few hours before the problem occurs again.

For the performance count, I found it may be useful for me to monitor the
memory status. However, there are so many counter names under memory and
process categories, will you suggest me to focus some of them in my
application?

Thanks again for your advice!

Regards,
James Wong

"Steven Cheng[MSFT]" <st*****@online .microsoft.com¼ ¶¼g©ó¶l¥ó·s»D:6 v************** @TK2MSFTNGHUB02 .phx.gbl...

Hi James,

From your description, you're encountering the following error:

"A Generic error occured in GDI+......."

in a winform application which print outo some string data into printer,
correct?

As for the "A Generic error occured in GDI+", it does be a very generic
exception that will sometimes occur in graphics application. I'm not sure
whether your applciation's code logic is very complex and contains many
other codelogic (not related to the GDI+ printing)? if so, I would suggest
you try creating a simplified project that dedicate the GDI+ processing to
see whether you can reproduce the issue.

For memory specific issue, a commom diagnostic means is using the
performance counter(process memory) to montior the managed and unmanaged
memory usage of your application's running process. You can check whether
there is particular memory pressure(at unmanaged or managed memory ...).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

=============== =============== =============== =====

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

=============== =============== =============== =====

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Steven Cheng[MSFT]]

Thanks for your reply James,

For memory specific performance counters, the following twos are very
useful:

category counter name

Process Private Bytes
NET CLR Memory #Bytes in all Heaps

"Private Bytes" counter(of Process category) is used to inspect the
physical private bytes consumed by your application process

"#Bytes in all Heaps" counter(of .NET CLR Memory category) is used to check
all the bytes in .NET managed heap

Here is a good msdn reference introducing production debugging of .NET
application

#Production Debugging for .NET Framework Applications
http://msdn2.microsoft.com/en-us/library/ms954591.aspx

And normally, memory issue in .net framework application will possibly be
caused by following things:

Caching/Session state
Large amount of sites
Debug mode
XSLT Transformations/XML Serialization
Pinning
Binary Formatter
Large Object Heap
COM objects with Events
Blocked Finalizer

Hope this also helps some.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[James Wong]

Hi Steven,

Thanks again for your reply!

I'll try to figure out what's happen on my application.

Regards,
James Wong

"Steven Cheng[MSFT]" <st*****@online .microsoft.com¼ ¶¼g©ó¶l¥ó·s»D:k k************** @TK2MSFTNGHUB02 .phx.gbl...

Thanks for your reply James,

For memory specific performance counters, the following twos are very
useful:

category counter name

Process Private Bytes
NET CLR Memory #Bytes in all Heaps

"Private Bytes" counter(of Process category) is used to inspect the
physical private bytes consumed by your application process

"#Bytes in all Heaps" counter(of .NET CLR Memory category) is used to
check
all the bytes in .NET managed heap

Here is a good msdn reference introducing production debugging of .NET
application

#Production Debugging for .NET Framework Applications
http://msdn2.microsoft.com/en-us/library/ms954591.aspx

And normally, memory issue in .net framework application will possibly be
caused by following things:

Caching/Session state
Large amount of sites
Debug mode
XSLT Transformations/XML Serialization
Pinning
Binary Formatter
Large Object Heap
COM objects with Events
Blocked Finalizer

Hope this also helps some.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no
rights.

[=?Utf-8?B?RGVubmlz?=]

Just a wild guess, but are you sure you dispose of the brush and font used to
draw the string after each call to your routine.
--
Dennis in Houston
"James Wong" wrote:

Hi Steven,

Thanks again for your reply!

I'll try to figure out what's happen on my application.

Regards,
James Wong

"Steven Cheng[MSFT]" <st*****@online .microsoft.com ¼Â¶Â¼g©ó¶lÂ¥ ó·s»D:kk**** **********@TK2M SFTNGHUB02.phx. gbl...

Thanks for your reply James,

For memory specific performance counters, the following twos are very
useful:

category counter name

Process Private Bytes
NET CLR Memory #Bytes in all Heaps

"Private Bytes" counter(of Process category) is used to inspect the
physical private bytes consumed by your application process

"#Bytes in all Heaps" counter(of .NET CLR Memory category) is used to
check
all the bytes in .NET managed heap

Here is a good msdn reference introducing production debugging of .NET
application

#Production Debugging for .NET Framework Applications
http://msdn2.microsoft.com/en-us/library/ms954591.aspx

And normally, memory issue in .net framework application will possibly be
caused by following things:

Caching/Session state
Large amount of sites
Debug mode
XSLT Transformations/XML Serialization
Pinning
Binary Formatter
Large Object Heap
COM objects with Events
Blocked Finalizer

Hope this also helps some.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no
rights.

[Steven Cheng[MSFT]]

Hi James,

If you get any progress or if there is anything else we can help you,
please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[James Wong]

Hi Dennis,

Thanks for your hints. I don't dispose brush or font after drawing. Do you
mean I have to do so and it may be the cirtical point to my problem?
Anyway, I'll try to dispose them and see the result.

Regards,
James Wong

"Dennis" <De****@discuss ions.microsoft. com¼¶¼g©ó¶l¥ó·s »D:B5********** *************** *********@micro soft.com...

Just a wild guess, but are you sure you dispose of the brush and font used
to
draw the string after each call to your routine.
--
Dennis in Houston

[Steven Cheng[MSFT]]

Hi James,

For those graphics objects such as Brush, Bitmap, Font... they will hold
win32 unmanaged resource handle, thus, whenever you have used large number
of such objects and haven't explcitly dispose them at ealiear time, they'll
hold significant operating system resource(GDI handles). Therefore, you're
recommended to explicitly dispose them after finishing use them.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

[James Wong]

Hi Steven,

Thanks for your information!

By the way, I've got another problem related to .NET framework and I've
posted it with subject ".NET runtime error" in newsgroup .dotnet.framewo rk.
However, there is no response there for over two days. Would you have a
look and give me some hints? Thanks a lot!

Regards,
James Wong

"Steven Cheng[MSFT]" <st*****@online .microsoft.com¼ ¶¼g©ó¶l¥ó·s»D:N c************** **@TK2MSFTNGHUB 02.phx.gbl...

Hi James,

For those graphics objects such as Brush, Bitmap, Font... they will hold
win32 unmanaged resource handle, thus, whenever you have used large number
of such objects and haven't explcitly dispose them at ealiear time,
they'll
hold significant operating system resource(GDI handles). Therefore, you're
recommended to explicitly dispose them after finishing use them.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no
rights.