Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Heap –l gives CONTEXT_BUSY_BLOCK

60 views
Skip to first unread message

Kjell Gunnar

unread,
Jun 28, 2004, 8:43:57 AM6/28/04
to
In response to !heap –l, I got a very large number of lines with
CONTEXT_BUSY_BLOCK xxxxxx address isn't from the heap
.

What does this means?
What can I do to investigate if this is a symptom of an error ?

Thank You
Kjell Gunnar.
------------------ Some output ------------------

CONTEXT_BUSY_BLOCK 0b61e410 address isn't from the heap
CONTEXT_BUSY_BLOCK 0b620418 address isn't from the heap
CONTEXT_BUSY_BLOCK 0b622430 address isn't from the heap
CONTEXT_BUSY_BLOCK 0b623998 address isn't from the heap
Scanning VM ...
Entry User Heap Segment Size PrevSize Unused Flags
-----------------------------------------------------------------------------
51222 leaks detected.

0:000> !heap -x 0b623998
Entry User Heap Segment Size PrevSize Unused Flags
-----------------------------------------------------------------------------
0b623998 0b6239a0 02c90000 0b3b0000 2018 1568 c busy

Environment:
XP, SP 1 + all critical hotfixes
Windbg: 6.3.0017.0

Ivan Brugiolo [MSFT]

unread,
Jun 28, 2004, 12:49:12 PM6/28/04
to
I cannot find the strings reported below in the current sources for exts.dll
Which debugger version are you using ?

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Kjell Gunnar" <kten...@hotmail.com> wrote in message
news:880d4bed.04062...@posting.google.com...
> In response to !heap -l, I got a very large number of lines with

Kjell Gunnar

unread,
Jun 29, 2004, 3:06:57 AM6/29/04
to
Hi
Thank you for investigation :-)
I have the latest (for me) WinDbg, - 6.3.0017.0.
The app is a large MFC 7.0 with some .net extensions

Regards
Kjell Gunnar.

Here is output from version.

0:000> version
Windows XP Version 2600 (Service Pack 1) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 5.1.2600.1106 (xpsp1.020828-1920)
Debug session time: Tue Jun 29 08:43:59 2004
System Uptime: 0 days 19:21:12.710
Process Uptime: 0 days 18:59:40.800
Kernel time: 0 days 0:00:04.846
User time: 0 days 0:00:05.437
Live user mode: <Local>
command line: '"C:\windbg\windbg.exe" ' Debugger Process 0xDA4
dbgeng: image 6.3.0017.0, built Tue May 25 02:27:51 2004
[path: C:\windbg\dbgeng.dll]
dbghelp: image 6.3.0017.0, built Tue May 25 02:28:03 2004
[path: C:\windbg\dbghelp.dll]
DIA version: 40416
Extension DLL search Path:
C:\windbg\winext;C:\windbg\winext\arcade;C:\windbg\WINXP;C:\windbg\pri;C:\windbg;C:\windbg\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;<xxx>;C:\Program
Files\Rational\common;C:\windbg;C:\Program Files\Microsoft Visual
Studio\Common\Tools\WinNT;C:\Program Files\Microsoft Visual
Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual
Studio\Common\Tools;C:\Program Files\Microsoft Visual
Studio\VC98\bin;<xxxx>
Extension DLL chain:
C:\windbg\clr10\sos: image 6.3.0017.0, API 1.0.0, built Tue May 18
21:23:19 2004
[path: C:\windbg\clr10\sos.dll]
dbghelp: image 6.3.0017.0, API 6.0.6, built Tue May 25 02:28:03
2004
[path: C:\windbg\dbghelp.dll]
ext: image 6.3.0017.0, API 1.0.0, built Tue May 25 20:23:08 2004
[path: C:\windbg\winext\ext.dll]
exts: image 6.3.0017.0, API 1.0.0, built Tue May 18 21:23:14 2004
[path: C:\windbg\WINXP\exts.dll]
uext: image 6.3.0017.0, API 1.0.0, built Tue May 18 21:23:18 2004
[path: C:\windbg\winext\uext.dll]
ntsdexts: image 6.0.4071.0, API 1.0.0, built Tue May 11 03:26:52
2004
[path: C:\windbg\WINXP\ntsdexts.dll]
Version 5.1 (Build 2600: Service Pack 1) Uniprocessor Free


"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<O8D5y$SXEH...@TK2MSFTNGP12.phx.gbl>...

Ivan Brugiolo [MSFT]

unread,
Jun 29, 2004, 12:37:33 PM6/29/04
to
do you have a dump that exibits the problem that you can send over ?
[remove the -online- part from the replay-to address]

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Kjell Gunnar" <kten...@hotmail.com> wrote in message
news:880d4bed.04062...@posting.google.com...

Kjell Gunnar

unread,
Jun 30, 2004, 4:38:30 AM6/30/04
to
Great !
I hope you have received my mail by now.
Kjell Gunnar

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<uxDAhdfX...@TK2MSFTNGP11.phx.gbl>...

Ivan Brugiolo [MSFT]

unread,
Jun 30, 2004, 12:25:19 PM6/30/04
to
Sure, I go the dump.
I will post there same the answer I sent here,
since it explains an interesting method to attack problems

I opened the dump, and I run the command with no errors

0:008> !heap -l
Heap 00150000
Heap 00250000
Heap 00260000
Heap 00de0000
Heap 01320000
Heap 01330000
Heap 013d0000
Heap 01510000
Heap 01550000
Heap 01560000
Heap 015a0000
Heap 015e0000
Heap 01620000
Heap 01660000
Heap 01770000
Heap 01850000
Heap 01890000
Heap 018d0000
Heap 01910000
Heap 01950000
Heap 02920000
Heap 019d0000
Heap 01b40000
Heap 02c90000
Heap 09600000
Heap 0a140000
Heap 0b220000
Scanning Virtual Memory failed.No leaks detected.
0:008>

Let me show hot to attack this problem.
[some actual output is omitted for clarity]

First, the two heap below have the most of the committed bytes.
Let's get the statistics of the busy blocks

0:008> !heap -stat -h 01330000
_PEB::OSCSDVersion 0100
heap @ 01330000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
00000030 000012B6 - 00038220 (7.11)
00002714 00000016 - 00035BB8 (6.81)
00002710 00000016 - 00035B60 (6.81)
00000024 00000FEC - 00023D30 (4.54)
00000014 00001AFD - 00021BC4 (4.28)
0000001A 00001486 - 0002159C (4.23)
0000007C 00000441 - 00020F7C (4.18)
000000A4 0000031C - 0001FDF0 (4.04)
0000001C 00000ACD - 00012E6C (2.40)
0000001B 00000A29 - 00011253 (2.17)
00000018 00000B6D - 00011238 (2.17)
00000028 00000661 - 0000FF28 (2.02)
00000019 00000A21 - 0000FD39 (2.01)
00000050 000002E2 - 0000E6A0 (1.83)
00000020 00000692 - 0000D240 (1.67)
00000010 00000D0A - 0000D0A0 (1.65)
0000000C 000010EB - 0000CB04 (1.61)
0000001F 00000609 - 0000BB17 (1.48)
00000928 00000014 - 0000B720 (1.45)
0000001D 000005F7 - 0000ACFB (1.37)
0:008> !heap -stat -h 2c90000
heap @ 02c90000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
00002000 000000AB - 00156000 (30.05) <<<<<<<<<<<<<<<<<<<<<<< we are
after this size
0004329C 00000001 - 0004329C (5.90)
0002F00C 00000001 - 0002F00C (4.13)
00009000 00000005 - 0002D000 (3.95)
0002C514 00000001 - 0002C514 (3.89)
00007000 00000006 - 0002A000 (3.69)
00006000 00000007 - 0002A000 (3.69)
0002800C 00000001 - 0002800C (3.51)
0002600C 00000001 - 0002600C (3.34)
00004000 00000009 - 00024000 (3.16)
0002200C 00000001 - 0002200C (2.99)
0001FD24 00000001 - 0001FD24 (2.80)
00005000 00000006 - 0001E000 (2.64)
00003000 00000009 - 0001B000 (2.37)
00008000 00000003 - 00018000 (2.11)
00000158 00000110 - 00016D80 (2.01)
00000024 000009EB - 0001650C (1.96)
000158A4 00000001 - 000158A4 (1.89)
00004028 00000005 - 000140C8 (1.76)
000000C4 0000010A - 0000CBA8 (1.12)

let's attack the size 0x2000

0:008> !heap -flt s 2000
_HEAP @ 00150000
_HEAP @ 00250000
_HEAP @ 00260000
_HEAP @ 00DE0000
_HEAP @ 01320000
_HEAP @ 01330000
_HEAP @ 013D0000
_HEAP @ 01510000
_HEAP @ 01550000
_HEAP @ 01560000
_HEAP @ 015A0000
_HEAP @ 015E0000
_HEAP @ 01620000
_HEAP @ 01660000
_HEAP @ 01770000
_HEAP @ 01850000
_HEAP @ 01890000
_HEAP @ 018D0000
_HEAP @ 01910000
_HEAP @ 01950000
_HEAP @ 02920000
_HEAP @ 019D0000
_HEAP @ 01B40000
_HEAP @ 02C90000
09055008: 0401 : 021f [01] - 09055010 (00002000) - (busy)
09057010: 0401 : 0401 [01] - 09057018 (00002000) - (busy)
0905C020: 0401 : 0005 [01] - 0905C028 (00002000) - (busy)
0905F5A8: 0401 : 0011 [01] - 0905F5B0 (00002000) - (busy)
09063AA8: 0401 : 049f [01] - 09063AB0 (00002000) - (busy)
09066F50: 0401 : 002c [01] - 09066F58 (00002000) - (busy)
0906B318: 0401 : 001a [01] - 0906B320 (00002000) - (busy)
0906D320: 0401 : 0401 [01] - 0906D328 (00002000) - (busy)
09099500: 0401 : 4c03 [01] - 09099508 (00002000) - (busy)
0909B590: 0401 : 0002 [01] - 0909B598 (00002000) - (busy)
090C9920: 0401 : 0006 [01] - 090C9928 (00002000) - (busy)
090CBAC8: 0401 : 0002 [01] - 090CBAD0 (00002000) - (busy)
090CDB68: 0401 : 0005 [01] - 090CDB70 (00002000) - (busy)
090D0000: 0401 : 0002 [01] - 090D0008 (00002000) - (busy)
090D2008: 0401 : 0401 [01] - 090D2010 (00002000) - (busy)
090E8000: 0401 : 0005 [01] - 090E8008 (00002000) - (busy)
090EAFF0: 0401 : 0006 [01] - 090EAFF8 (00002000) - (busy)
090EEB10: 0401 : 0004 [01] - 090EEB18 (00002000) - (busy)
090F2C08: 0401 : 000c [01] - 090F2C10 (00002000) - (busy)

let's find the leve-1 correlation of the allocation

0:008> !heap -srch 09C07058
_HEAP @ 02C90000
in HEAP_ENTRY: Size : Prev Flags - UserPtr UserSize - state
0B7DA920: 002c : 002c [01] - 0B7DA928 (00000158) - (busy)
diasymreader!Mod1::`vftable'

let's find how many of these guys are around

0:008> !heap -srch 51a980d0
_HEAP @ 02C90000
in HEAP_ENTRY: Size : Prev Flags - UserPtr UserSize - state
02C98A20: 002c : 000d [01] - 02C98A28 (00000158) - (busy)
diasymreader!Mod1::`vftable'
_HEAP @ 02C90000
in HEAP_ENTRY: Size : Prev Flags - UserPtr UserSize - state
02C98B80: 002c : 002c [01] - 02C98B88 (00000158) - (busy)
diasymreader!Mod1::`vftable'

You can repeat the process for all the "most-offending-sizes" in the
`!heap -stat -h`

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Kjell Gunnar" <kten...@hotmail.com> wrote in message

news:880d4bed.04063...@posting.google.com...

0 new messages