Hello,
We're having a memory leak problem, and it looks like it comes from Windows.
Windows leaks about 50-100 bytes anytime a driver gets loaded/unloaded,
affecting both the device insertion case and manual load/unload of drivers via
service control manager.
The problem can easily be seen by using the ddk example and pooltag utility.
- Using WDK, build <wdk>\src\general\ioctl\sys driver, and install it
- run the awesome pooltag utility from OSR
(http://www.osronline.com/article.cfm?article=98)
Steps to reproduce:
- launch pooltag utility. Filter the result to view only 'IoSe' and 'Pp '
tags.
- install sioctl.sys from the ddk so you can "net start" and "net stop" it
- anytime we "net start" and "net stop" sioctl driver, we see:
- On Vista 32, 1-block 40-byte leak from 'IoSe', and 1-block 32-byte leak
from 'Pp '
- On Vista 32 SP1 RC1, same thing
- On XP SP2, no leak from 'IoSe' pool, but 1-block leak from 'Pp ' pool
- No leak on Win2000
We did more debugging, using the poolhittag trick, and here's the result on
Vista32:
kd> ed poolhittag 'eSoI'
=====================>>>> HERE : "net start sioctl"
kd> g
*** ERROR: Module load completed but symbols could not be loaded for
sioctl.sys
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
81c578ce cc int 3
kd> k
ChildEBP RetAddr
82cbb984 81d85327 nt!DbgBreakPoint
82cbb9a8 81d85287 nt!IopCreateSecurityDescriptorPerType+0x86
82cbb9c8 81d82fef nt!IopCreateDefaultDeviceSecurityDescriptor+0x115
82cbba78 909b4c11 nt!IoCreateDevice+0xcc
WARNING: Stack unwind information not available. Following frames may be
wrong.
82cbbad4 909b7054 sioctl+0x4c11
82cbbb18 81d871e0 sioctl+0x7054
82cbbcfc 81d8766f nt!IopLoadDriver+0x7ec
82cbbd44 81c78e18 nt!IopLoadUnloadDriver+0x70
82cbbd7c 81e254a8 nt!ExpWorkerThread+0xfd
82cbbdc0 81c9145e nt!PspSystemThreadStartup+0x9d
00000000 00000000 nt!KiThreadStartup+0x16
=====================>>>> HERE : "net stop sioctl"
kd> ed poolhittag ' pP'
=====================>>>> HERE : "net start sioctl".
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
81c578ce cc int 3
kd> k
ChildEBP RetAddr
82cbb9c0 81d9e494 nt!DbgBreakPoint
82cbb9d0 81da2894 nt!IopAllocateUnicodeString+0x1b
82cbb9e4 81da2080 nt!PnpConcatenateUnicodeStrings+0x1e
82cbba40 81da353b nt!PipServiceInstanceToDeviceInstance+0x133
82cbba9c 81da2922 nt!PnpIsAnyDeviceInstanceEnabled+0xd7
82cbbb14 81d86e6b nt!PnpPrepareDriverLoading+0x61
82cbbcfc 81d8766f nt!IopLoadDriver+0x478
82cbbd44 81c78e18 nt!IopLoadUnloadDriver+0x70
82cbbd7c 81e254a8 nt!ExpWorkerThread+0xfd
82cbbdc0 81c9145e nt!PspSystemThreadStartup+0x9d
00000000 00000000 nt!KiThreadStartup+0x16
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
81c578ce cc int 3
kd> k
ChildEBP RetAddr
82cbba48 81da355a nt!DbgBreakPoint
82cbba9c 81da2922 nt!PnpIsAnyDeviceInstanceEnabled+0xf6
82cbbb14 81d86e6b nt!PnpPrepareDriverLoading+0x61
82cbbcfc 81d8766f nt!IopLoadDriver+0x478
82cbbd44 81c78e18 nt!IopLoadUnloadDriver+0x70
82cbbd7c 81e254a8 nt!ExpWorkerThread+0xfd
82cbbdc0 81c9145e nt!PspSystemThreadStartup+0x9d
00000000 00000000 nt!KiThreadStartup+0x16
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
81c578ce cc int 3
kd> k
ChildEBP RetAddr
82cbb93c 81dae37a nt!DbgBreakPoint
82cbb994 81dae0ff nt!PiUpdateDriverDBCache+0xf9
82cbba00 81dadf6b nt!PiIsDriverBlocked+0x141
82cbba58 81dadd64 nt!PiLookupInDDB+0x160
82cbba90 81da2b28 nt!PpCheckInDriverDatabase+0x69
82cbbb14 81d86e6b nt!PnpPrepareDriverLoading+0x267
82cbbcfc 81d8766f nt!IopLoadDriver+0x478
82cbbd44 81c78e18 nt!IopLoadUnloadDriver+0x70
82cbbd7c 81e254a8 nt!ExpWorkerThread+0xfd
82cbbdc0 81c9145e nt!PspSystemThreadStartup+0x9d
00000000 00000000 nt!KiThreadStartup+0x16
From the trace, it's easy to conclude that there's one memory leak from
IoCreateDevice() and another memory leak from unicode string manipulation
during driver load.
I tried calling IoCreateDeviceSecure() instead, but the result is the same
leak, since IoCreateDeviceSecure() ends up calling IoCreateDevice():
82cbb984 81d85327 nt!DbgBreakPoint
82cbb9a8 81d85287 nt!IopCreateSecurityDescriptorPerType+0x86
82cbb9c8 81d82fef nt!IopCreateDefaultDeviceSecurityDescriptor+0x115
82cbba78 90996c11 nt!IoCreateDevice+0xcc
82cbbad4 90999054 sioctl!IoDevObjCreateDeviceSecure+0xe0
[d:\vistartm\base\wdmlib\wdmsec\io\iodevobj.c @ 284]
82cbbb18 81d871e0 sioctl!DriverEntry+0x44
[d:\winddk\src\general\ioctl\sys\sioctl.c @ 131]
82cbbcfc 81d8766f nt!IopLoadDriver+0x7ec
82cbbd44 81c78e18 nt!IopLoadUnloadDriver+0x70
82cbbd7c 81e254a8 nt!ExpWorkerThread+0xfd
82cbbdc0 81c9145e nt!PspSystemThreadStartup+0x9d
00000000 00000000 nt!KiThreadStartup+0x16
- Has anyone else seen this before?
- Is this a genuine Windows kernel leak bug?
Thanks!
--
Irwan Djajadi
National Instruments -- http://www.ni.com
(4FJ8B6VF)