Platform SDK Shell >> Memory Leak in Winlogon.exe

by TWF0dCBCYWVy » Sat, 16 Apr 2005 02:40:02 GMT

Hello everyone,

This is my first post on this board. I'm reporting on an apparent memory
leak in winlogon.

I have initially prepared a Word document, since I collected the relevant
screenshots but it is not clear whether I can attach it to this post. The
following text is taken from the document.

The document as well as the bitmaps I used in my tests are available upon
request.

Please let me know what you think.

Thanks,
gabriel

---------------------------------------------------------------

SUMMARY

The amount of virtual memory used by winlogon.exe increases with repeated
login/logout operations when the desktop background is set to a bitmap
picture with particular characteristics. The login/logout operations must
occur at the console.

This was problem was detected on the Windows 2003 Server operating system.
It was also reproduced on the Windows 2000 Server. It causes serious
performance problems with servers that run mission critical, execution time
and memory dependent applications.


PROBLEM DESCRIPTION

Assume that an application modifies Windows registry for a particular user
to set the background to the desired picture file. Alternatively, this can be
done manually. When this picture has a certain format, it will not be
displayed on the desktop although the Control Panel settings indicate it as
the default background. If the user for whom this background was set logs in
and out repeatedly, the amount of virtual memory available on the system will
continue to decrease. The delta is accounted for in winlogon.exe.

There is no restriction for the length of time during which the login/logoff
operations must occur. In practice, network operators execute scheduled
checks and therefore the problem usually surfaces after days of weeks,
depending on the system configuration and the periodicity of these events.

Rebooting the system is the only way to recovery.


PROBABLE CAUSE

The delta increase in virtual memory observed between two consecutive login
operations seems to be in direct correlation with the amount needed to store
the color table.

Since the picture is not displayable, this memory should not be allocated or
it should be freed after the inconsistency is determined.


EXAMPLE

Consider a bitmap picture created using Windows Paint - spaint.exe The
original bitmap information header is given in Table 1. Using a hexadecimal
editor on a copy of the original file, the header is changed to indicate that
the picture is using 16 million colors (see Table 2).

Table 1 - Original BITMAPINFOHEADER

biSize ..................... 40
biWidth ................... 546
biHeight .................. 157
biPlanes .................. 1
biBitCount ............... 24
biCompression ........ BI_RGB
biSizeImage ............ 257480
biXPelsPerMeter ...... 0
biYPelsPerMeter ...... 0
biClrUsed ................ 0
biClrImportant ......... 0

Table 2 - Modified BITMAPINFOHEADER

biSize ..................... 40
biWidth ................... 546
biHeight .................. 157
biPlanes .................. 1
biBitCount ............... 24
biCompression ........ BI_RGB
biSizeImage ............ 257480
biXPelsPerMeter ...... 0
biYPelsPerMeter ...... 0
biClrUsed ................ 16777216
biClrImportant ......... 16777216

Let us call esktop.bmpand esktop.1.bmpthe original and the modified
pictures respectively.

Next, set the KCU/Desktop/Wallpaperto the fully qualified path to
esktop.bmp Open Control Panel\Display on the Desktop tab. Verify that the
picture is shown in the preview box. Reboot the system and confirm that the
esktop.bmpwas applied to the desktop. Log in and out several times and
check the virtual memory for inlogon.exeafter each login. This figure
should not show large variations regardless of the initial allocation.

The next step is to configure esktop.1.bmpas wallpaper by changing the
KCU/Desktop/Wallpaperkey to the fully qualified path to esktop.1.bmp
Verify that the new picture is not loaded in the preview box as suggested in
the ackgroundlist. Reboot and confirm that the new background is not set.
Log in and out several times. The amount of virtual memory used by
inlogon.exeis entirely different from the levels seen in the tests with
esktop.bmp The increase observed after each login is about 64 MB, which
is the size of the color table for this picture. Eventually this amount
settles to a high value, in my case about 1.6 GB.

---------------------------------------------------------------




Platform SDK Shell >> Memory Leak in Winlogon.exe

by Jim Barry » Tue, 19 Apr 2005 00:31:02 GMT


our modified bitmap is invalid - if biClrUsed is nonzero, then that number of colour table entries should follow the BITMAPINFOHEADER structure. I suppose when Windows tries to read the monster 64 meg colour table, it encounters a read error but forgets to clean up the memory it allocated. You can certainly consider this a bug, but then again why not just stick to using valid bitmap files? Anyway, unless you have an MSDN subscription and you post with your registered address, nobody from Microsoft is likely to respond here. If you need a response, you will have to contact Product Support Services directly.

--
Jim Barry, MVP for Windows SDK

Matt Baer wrote:
> modified pictures respectively>
>>
> Next, set the KCU/Desktop/Wallpaperto the fully qualified path >o
> esktop.bmp Open Control Panel\Display on the Desktop tab. Ver>fy
> that the picture is shown in the preview box. Reboot the system >nd
> confirm that the esktop.bmpwas applied to the desktop. Log in>and
> out several times and check the virtual memory for inlogon.e>e > after each login. This figure should not show large varia>ions
> regardless of the initial allocat>on.>
>
> The next step is to configure esktop.1.bmpas wallpa>er by
> changing the KCU/Desktop/Wallpaperkey to the fully qualifi>d path
> to esktop.1.bmp Verify that the new picture is not loade> in the
> preview box as suggested in the ackgroundlist. Reboot an> confirm
> that the new background is not set. Log in and out several t>mes. The
> amount of virtual memory used by inlogon.exeis entirely>different
> from the levels seen in the tests with esktop.bmp T>e increase
> observed after each login is about 64 MB, which is the >ize of the
> color table for this picture. Eventually this amount s>ttles to a
> high value, in my case abo>t 1>6 GB.
>
> ---------------------------------------------------------------



Platform SDK Shell >> Memory Leak in Winlogon.exe

by TWF0dCBCYWVy » Tue, 19 Apr 2005 00:59:01 GMT

im,

The bitmap that I used for testing is modified by me.

However the bitmap that stared all this is created using
either Photoshop or Corel PhotoPaint (the guy who
actually produced this wallpaper cannot remember).

This bug meant a lot of trouble for my company.

We have an up-to-date MSDN subscription. I posted here
hoping that someone from Microsoft will read.

Thanks,
gabriel



"Jim Barry" wrote:

> > esktop.bmp Open Control Panel\Display on the Desktop tab. Ver>f>
> > that the picture is shown in the preview box. Reboot the system >n>
> > confirm that the esktop.bmpwas applied to the desktop. Log in>a>d
> > out several times and check the virtual memory for inlogon.e>e>€ > > after each login. This figure should not show large varia>i>ns
> > regardless of the initial allocat>o>. >>>>
> > The next step is to configure esktop.1.bmpas wallpa>e> by
> > changing the KCU/Desktop/Wallpaperkey to the fully qualifi>d>path
> > to esktop.1.bmp Verify that the new picture is not loade> >n the
> > preview box as suggested in the ackgroundlist. Reboot an> >onfirm
> > that the new background is not set. Log in and out several t>m>s. The
> > amount of virtual memory used by inlogon.exeis entirely>d>fferent
> > from the levels seen in the tests with esktop.bmp T>e>increase
> > observed after each login is about 64 MB, which is the >i>e of the
> > color table for this picture. Eventually this amount s>t>les to a
> > high value, in my case abo>t>1.6>G>.
> >
> > ---------------------------------------------------->----------


Memory Leak in Winlogon.exe

by Jim Barry » Tue, 19 Apr 2005 02:20:45 GMT




OK, I see.


If you make sure you post using the address you have registered with Microsoft, you are supposed to get a response within two working days. See here for details:

http://msdn.microsoft.com/subscriptions/managednewsgroups

--
Jim Barry, MVP for Windows SDK


Memory Leak in Winlogon.exe

by TWF0dCBCYWVy » Tue, 19 Apr 2005 03:47:03 GMT

Jim,

thanks and hope that MSFT will look into this.

gabriel







Memory Leak in Winlogon.exe

by Jim Barry » Tue, 19 Apr 2005 06:54:00 GMT

> thanks and hope that MSFT will look into this.

If you still don't get a response here, you could try submitting a bug report using one of the free "support incidents" that come with the MSDN subscription. As this is "obviously" a bug, the support incident should be credited back to you, assuming the bug is confirmed.

--
Jim Barry, MVP for Windows SDK