This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why two functions print the same address?
I am working with PDB symbol files for an application which processes them (via the DbgHelp API). I have come across a strange issue where a PDB file will contain multiple different public symbol entries for the same address!
For example, using the latest Microsoft PDB file for kernel32.dll (wow64) on Windows 7 (x64), we can dump the following information and see 31 different entries for the same address 0x10b1a6e:
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86>dbh.exe c:\symbols\wkernel32.pdb\D08F1E131D1F4D97B4AB2F64E00CFC8B2\wkernel32.pdb m 10b1a6e
index address name
7a 10b1a6e : MFInitAttributesFromBlob
179 10b1a6e : MFCreateSourceReaderFromURL
2fc 10b1a6e : MFCreateASFMediaSinkActivate
5b6 10b1a6e : MFCreateWMVEncoderActivate
61d 10b1a6e : MFAddPeriodicCallback
64c 10b1a6e : MFPutWorkItem
825 10b1a6e : MFCreateAlignedMemoryBuffer
c12 10b1a6e : MFGetAttributesAsBlob
d26 10b1a6e : MFCreateMFVideoFormatFromMFMediaType
f1a 10b1a6e : MFFrameRateToAverageTimePerFrame
1129 10b1a6e : MFCreateProxyLocator
1277 10b1a6e : MFSerializeAttributesToStream
12b3 10b1a6e : MFEnumDeviceSources
146d 10b1a6e : MFCreateWMAEncoderActivate
164c 10b1a6e : MFBeginUnregisterWorkQueueWithMMCSS
1bfc 10b1a6e : MFCreateSourceReaderFromMediaSource
1d25 10b1a6e : MFInitMediaTypeFromWaveFormatEx
1d72 10b1a6e : MFGetStrideForBitmapInfoHeader
1efb 10b1a6e : CopyPropertyStore
1f8d 10b1a6e : MFDeserializePresentationDescriptor
1fb5 10b1a6e : MFCreateSampleGrabberSinkActivate
1fe4 10b1a6e : MFCreateASFStreamingMediaSinkActivate
23a3 10b1a6e : MFDeserializeAttributesFromStream
24c0 10b1a6e : MFConvertFromFP16Array
26f7 10b1a6e : MFSerializePresentationDescriptor
2877 10b1a6e : MFCreatePresentationDescriptor
2ab7 10b1a6e : MFCreateSourceReaderFromByteStream
2b4a 10b1a6e : MFGetWorkQueueMMCSSClass
2e08 10b1a6e : MFInitMediaTypeFromMFVideoFormat
2ef0 10b1a6e : MFCreateSinkWriterFromMediaSink
2eff 10b1a6e : MFConvertToFP16Array
The above example is one of many addresses containing duplicates. Normally there is one symbol entry at any address. It simply doesn't make sense to have multiple symbol entries for the same address AFAIK!!
Can anybody enlighten me as to:
Why this is happening?
Can these duplicate entries be resolved into there unique location?
Thanks.
There are multiple symbols for the same address because all the functions are the same. In your case, they are all functions that go
HRESULT MFBlahBlahBlah(...)
{
return E_NOTIMPL;
}
Related
Reproduce
With Xcode 14.1, following steps can reproduce the phenomenon:
add a pdf file to the assets, and in attributes inspector, select "Preserve Vector Data", set "Scales" as "Single Scale".
run Xcode->Product->Archive
follow the instruction of create the app size report from apple official site. In the archives list, select "Distribute App" -> Ad Hoc ->App Thinning: All compatible device variants -> Next -> Automatically menage signing -> Next -> Export.
Now we check the exported folder, in the sub folder named "Apps", we can get 3 ipas.
-rw-r--r--# 1 xxxx staff 386048 Nov 10 21:01 111002-582C7144-401C-4F99-8FA7-3B164292726E.ipa
-rw-r--r--# 1 xxxx staff 639517 Nov 10 21:01 111002-5A4FE73D-2DCB-4079-BB68-59FA54D31921.ipa
-rw-r--r-- 1 xxxx staff 1190004 Nov 10 21:01 111002.ipa
choose one specific ipa (NOT the universal one 111002.ipa), we can choose one base on file "App Thinning Size Report.txt", unzip that ipa, enter the app folder, now we can find the file which name is "Assets.car".
we run the script "xcrun --sdk iphoneos assetutil --info Assets.car", then we get a output message, part of it like this:
{
"AssetType" : "Image",
"BitsPerComponent" : 8,
"ColorModel" : "RGB",
"Colorspace" : "srgb",
"Compression" : "deepmap-lzfse",
"Encoding" : "ARGB",
"Idiom" : "universal",
"Name" : "pdf",
"NameIdentifier" : 19593,
"Opaque" : false,
"PixelHeight" : 842,
"PixelWidth" : 595,
"Preserved Vector Representation" : true,
"RenditionName" : "pdf.pdf",
"Scale" : 1,
"SHA1Digest" : "5C71A688035EDA13684D904E6F272BC9B0F7ABF8D5AFE1C44915FDC99AB5DC4E",
"SizeOnDisk" : 71134,
"State" : "Normal",
"Template Mode" : "automatic",
"Value" : "Off"
},
{
"AssetType" : "Image",
"BitsPerComponent" : 8,
"ColorModel" : "RGB",
"Colorspace" : "srgb",
"Compression" : "deepmap-lzfse",
"Encoding" : "ARGB",
"Idiom" : "universal",
"Name" : "pdf",
"NameIdentifier" : 19593,
"Opaque" : false,
"PixelHeight" : 2526,
"PixelWidth" : 1785,
"Preserved Vector Representation" : true,
"RenditionName" : "pdf.pdf",
"Scale" : 3,
"SHA1Digest" : "BB0E06CEB24DBF6A89D38BAFCBAE5D6322CED922FDD30E4A5E4A22C9079B7390",
"SizeOnDisk" : 369765,
"State" : "Normal",
"Template Mode" : "automatic",
"Value" : "Off"
},
{
"AssetType" : "Vector",
"Colorspace" : "generic",
"Height" : 842,
"Idiom" : "universal",
"Name" : "pdf",
"NameIdentifier" : 19593,
"RenditionName" : "pdf.pdf",
"Scale" : 1,
"SHA1Digest" : "03F9900F23A26D421A8A612372849CCFB2952E7C47D99DA514B770AE1908C283",
"SizeOnDisk" : 43409,
"State" : "Normal",
"Value" : "Off",
"Width" : 595
}
This means there are 3 files in the Assets.car. And we can use some tools to export them out. e.g QLCARFiles and we can get these 3 files.
-rw-r--r-- 1 xxxxx staff 43185 Nov 10 21:20 pdf.pdf
-rw-r--r-- 1 xxxxx staff 113023 Nov 10 21:20 pdf-UIAppearanceAny.png
-rw-r--r-- 1 xxxxx staff 343966 Nov 10 21:20 pdf-UIAppearanceAny#2x.png
My question is
as I already selected "Preserve Vector Data" in Xcode, why my device still get two unnecessary png files?
In my opinion, what my device need is only that pdf.pdf file, do not need these two png file.(pdf-UIAppearanceAny.png / pdf-UIAppearanceAny.png), these have no benefit except increased unnecessary ipa's size.
I also used svg file and can got same phenomenon, I googled a lot, no useful message found.
Could it be the minimum iOS version for your app is <= iOS 12?
The "vector data preservation" + SVG support is only available on macOS 10.15 or later, iOS 13 or later, and iPadOS 13 or later.
Else Xcode will fallback to generating png files when building an app archive.
The following blogs explain it a lot better than i can, have read.
https://sarunw.com/posts/svg-image-assets-supported-in-xcode12/
https://www.avanderlee.com/xcode/svg-image-assets/
https://www.willowtreeapps.com/craft/what-svg-support-means-for-your-ios-app-graphics
I have a VerifierDlls installed against an 3rd-party application. It kept getting crash due to invalid handle error:
APPLICATION_VERIFIER_HANDLES_INVALID_HANDLE (300)
Invalid handle exception for current stack trace.
This stop is generated if the function on the top of the stack passed an
invalid handle to system routines. Usually a simple kb command will reveal
what is the value of the handle passed (must be one of the parameters -
usually the first one). If the value is null then this is clearly wrong.
If the value looks ok you need to use !htrace debugger extension to get a
history of operations pertaining to this handle value. In most cases it
must be that the handle value is used after being closed.
Arguments:
Arg1: 00000000c0000008, Exception code.
Arg2: 0000008397afefd0, Exception record. Use .exr to display it.
Arg3: 0000008397afe9a0, Context record. Use .cxr to display it.
Arg4: 0000000000000000, Not used.
I'm wondering if there's a way to avoid it? I tried to hook CloseHandle and I don't know how to tell if the handle is invalid.
From procdump I can tell CloseHandle was the cause
00 00007ffd`cc963851 : 00000000`00000000 00000000`00000000 0000ab17`238a5e24 00000000`00000002 : ntdll!NtWaitForMultipleObjects+0x14
01 00007ffd`cc962ae5 : 00000000`000016d8 00000000`00000000 00000000`000016d8 00000000`00001000 : ntdll!WerpWaitForCrashReporting+0x6d
02 00007ffd`cc961b97 : 00000000`00000000 00000099`fecfd5c0 00000000`00000020 00007ffd`cc98d68a : ntdll!RtlReportExceptionHelper+0x269
03 00007ffd`ad70ecc1 : 00000099`fecfce60 00000000`00000300 00000223`d06f4280 00000000`00000000 : ntdll!RtlReportException+0x77
04 00007ffd`cc9b5eb0 : 00000000`00000000 00007ffd`cca9b5e0 00000223`d06f4280 00000223`d06f4280 : verifier!AVrfpVectoredExceptionHandler+0x2b1
05 00007ffd`cc98fa3b : 00000099`fecfdab0 00000099`fecfd5c0 00000000`00000000 00000000`deff7850 : ntdll!RtlpCallVectoredHandlers+0x104
06 00007ffd`cc9f960a : 00000000`00000000 00000000`00000000 00007ffd`ad735ef0 00000000`00000000 : ntdll!RtlDispatchException+0x6b
07 00007ffd`ad7067ea : 00007ffd`ad735ef0 00000000`00000000 00007ffd`ad728744 00007ffd`ad73dd40 : ntdll!KiUserExceptionDispatch+0x3a
08 00007ffd`ad70ec59 : 00000099`fecfe130 00000000`00000000 00000223`d06f4280 00000099`fecffd20 : verifier!VerifierStopMessageEx+0x6e2
09 00007ffd`cc9b5eb0 : 00000000`00000000 00007ffd`cca9b5e0 00000223`d06f4280 00000223`d06f4280 : verifier!AVrfpVectoredExceptionHandler+0x249
0a 00007ffd`cc98fa3b : 00000099`fecff090 00000099`fecfea60 00000223`d06d0000 00000000`deff7850 : ntdll!RtlpCallVectoredHandlers+0x104
0b 00007ffd`cc991a59 : 00000099`fecfe9c0 00000000`00000024 00000099`fecfe900 00007ffd`ccaa7870 : ntdll!RtlDispatchException+0x6b
0c 00007ffd`cc9f967a : 00000000`00000000 00000000`000007ac 00007ff6`8b94d3f3 00007ffd`cc9f5bd0 : ntdll!RtlRaiseException+0x2d9
0d 00007ffd`ad71e0e1 : 00000223`d43b1660 00007ffd`cb024700 00007ff6`8b94d3f3 00000000`000007ac : ntdll!KiRaiseUserExceptionDispatcher+0x3a
0e 00007ffd`c94d6d82 : 00000000`000007ac 00000223`d43b1660 00000223`d028e040 00000223`d028e040 : verifier!AVrfpNtClose+0x51
0f 00007ffd`ad7201ad : 00000000`000007ac 00000099`fecff310 00000223`d028e038 00000000`000007ac : KERNELBASE!CloseHandle+0x62
10 00007ffd`ad720218 : 00000000`00000000 00000223`d028e038 00000000`00000000 00000000`00000000 : verifier!AVrfpCloseHandleCommon+0xa1
11 00007ff6`8b94d3f3 : 00000223`d0742fb0 00000099`fecff310 00000223`d028e038 00000000`00000000 : verifier!AVrfpKernel32CloseHandle+0x28
Any ideas?
You can disable single application verifier checks. Run appverif (note there is a 64 and a 32 bit version) and locate the general type of error you have, like
Now comes the not very intuitive action: do a right click on that checkbox and choose "Verifier Stop Options"
You can then select stop option 300 (which is yours) and change the behavior. I don't know exactly what that does, since I never used it, but it sounds either "Ignore" or "Inactive" would be a good choice to get rid of them.
Don't forget to hit the "Save" button after closing the dialog.
The Settings will be stored in Registry somewhere below HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ (64 bit)
Is there any package or method that replicates Delphi's formatfloat method?
Examples of the intended output when given 1234.567:
##### : 1235
00000 : 01235
0 : 1235
#,##0 : 1,235
,0 : 1,235
0.#### : 1234.567
0.0000 : 1234.5670
Edit:
The formatting masks would still need to be in the same format as Delphi (preferably, can be parsed and treated if need be), as they are present in an external file and it needs to be compatible with both.
I have a user mode process which is hanging when calling NtClose. That NtClose is hanging while trying to acquire a lock in the kernel. I believe it's the lock to the handle table. Here's the kernel part of the stack:
THREAD fffffa800bd4fb50 Cid 277c.21d8 Teb: 000007fffff80000 Win32Thread: 0000000000000000 WAIT: (WrResource) KernelMode Non-Alertable
fffffa80047bad20 SynchronizationEvent
IRP List:
fffffa80049f49c0: (0006,0430) Flags: 00000404 Mdl: 00000000
Not impersonating
DeviceMap fffff8a000008bc0
Owning Process fffffa800c195060 Image: My_Service.exe
Attached Process N/A Image: N/A
Wait Start TickCount 455527 Ticks: 223 (0:00:00:03.478)
Context Switch Count 1703
UserTime 00:00:00.015
KernelTime 00:00:00.109
Win32 Start Address 0x000000013f509190
Stack Init fffff8800c3e0fb0 Current fffff8800c3e0790
Base fffff8800c3e1000 Limit fffff8800c3db000 Call 0
Priority 10 BasePriority 8 UnusualBoost 2 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff880`0c3e07d0 fffff800`02ccc972 : fffffa80`0bd4fb50 fffffa80`0bd4fb50 fffff880`00000000 00000000`00000003 : nt!KiSwapContext+0x7a
fffff880`0c3e0910 fffff800`02cddd8f : 00000000`00000000 fffff880`0af2d400 fffff880`00000068 fffff880`0af2d408 : nt!KiCommitThreadWait+0x1d2
fffff880`0c3e09a0 fffff800`02cb7086 : 00000000`00000000 fffffa80`0000001b 00000000`00000000 fffff880`009eb100 : nt!KeWaitForSingleObject+0x19f
fffff880`0c3e0a40 fffff800`02cdc1ac : ffffffff`fd9da600 fffffa80`047bad20 fffffa80`03e1d238 00000000`00000200 : nt!ExpWaitForResource+0xae
fffff880`0c3e0ab0 fffff880`016e6f88 : 00000000`00000000 fffff8a0`0d555010 fffff880`0af2d840 fffff8a0`0a71e576 : nt!ExAcquireResourceExclusiveLite+0x14f
fffff880`0c3e0b20 fffff880`01652929 : fffffa80`06fc72c0 fffffa80`049f49c0 fffff880`0af2d550 fffffa80`0bd4fb50 : Ntfs!NtfsCommonCleanup+0x2705
fffff880`0c3e0f30 fffff800`02ccea37 : fffff880`0af2d550 00000000`00000000 00000000`00000000 00000000`00000000 : Ntfs!NtfsCommonCleanupCallout+0x19
fffff880`0c3e0f60 fffff800`02cce9f8 : 00000000`00000000 00000000`00000000 fffff880`0c3e1000 fffff800`02ce2e42 : nt!KySwitchKernelStackCallout+0x27 (TrapFrame # fffff880`0c3e0e20)
fffff880`0af2d420 fffff800`02ce2e42 : 00000000`0000277c 00000000`00000002 00000000`00000002 fffff880`042f8965 : nt!KiSwitchKernelStackContinue
fffff880`0af2d440 fffff880`016529a2 : fffff880`01652910 00000000`00000000 fffff880`0af2d800 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff880`0af2d520 fffff880`016f3894 : fffff880`0af2d5f0 fffff880`0af2d5f0 fffff880`0af2d5f0 fffff880`0af2d760 : Ntfs!NtfsCommonCleanupOnNewStack+0x42
fffff880`0af2d590 fffff880`01145bcf : fffff880`0af2d5f0 fffffa80`049f49c0 fffffa80`049f4da8 fffffa80`03ef5010 : Ntfs!NtfsFsdCleanup+0x144
fffff880`0af2d800 fffff880`011446df : fffffa80`04e239a0 00000000`00000000 fffffa80`048cb100 fffffa80`049f49c0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`0af2d890 fffff800`02fe3fef : fffffa80`049f49c0 fffffa80`0c195060 00000000`00000000 fffffa80`04aa93d0 : fltmgr!FltpDispatch+0xcf
fffff880`0af2d8f0 fffff800`02fd1fe4 : 00000000`00000000 fffffa80`0c195060 fffff880`01165cb0 fffff800`02c64000 : nt!IopCloseFile+0x11f
fffff880`0af2d980 fffff800`02fd1da1 : fffffa80`0c195060 fffffa80`00000001 fffff8a0`18385220 00000000`00000000 : nt!ObpDecrementHandleCount+0xb4
fffff880`0af2da00 fffff800`02fd2364 : 00000000`0000cae8 fffffa80`0c195060 fffff8a0`18385220 00000000`0000cae8 : nt!ObpCloseHandleTableEntry+0xb1
fffff880`0af2da90 fffff800`02cd61d3 : fffffa80`0bd4fb50 fffff880`0af2db60 00000001`3f64afd8 00000000`00000000 : nt!ObpCloseHandle+0x94
My question is, how can I work out which other process/thread on the system has acquired this kernel resource using windbg? (By the way I'm looking at a full system dump from a customer, I don't have this reproduced in a debugger)
So the answer was to use kdext*.locks, this shows that the thread above was deadlocked with a System thread that belonged to one of Symantec's antivirus drivers.
The locks which were causing a problem here were kernel ERESOURCE locks. There's two versions of !locks I've discovered, one for user mode critical sections and the other for kernel mode locks
I'm just doing some debugging on a Windows 7 crash dump, and I've come across a singly-linked list that I'm not able to fully understand.
Here's the output from WinDBG:
dt _GENERAL_LOOKASIDE_POOL fffff80002a14800 -b
....
0x000 SingleListHead: _SINGLE_LIST_ENTRY
+0x000 Next: 0x0000000000220001
....
From what I've been reading, it seems that each singly linked list begins with a list head, which contains a pointer to the first element in the list, or null if the list is empty.
Microsoft state: MSDN article
For a SINGLE_LIST_ENTRY that serves as a list entry, the Next member
points to the next entry in the list, or NULL if there is no next
entry in the list. For a SINGLE_LIST_ENTRY that serves as the list
header, the Next member points to the first entry in the list, or NULL
if the list is empty.
I'm 99% sure this list contains some entries, but I don't understand how the value of 0x0000000000220001 is supposed to be pointing to anything. This value certainly doesn't resolve to a valid page mapping, so I can only assume it's some kind of offset. However, I'm not sure.
If anyone could help shine some light on this, I'd appreciate it.
Thanks
UPDATE
I've just found a document (translated from Chinese) that seems to explain the structure a little more. If anyone could offer some input on it, I'd appreciate it.
Lookaside List article
What I'm actually looking at is a lookaside list that Windows should be using for the allocation of IRPs, here's the full output from WinDBG (values changed from original question):
lkd> !lookaside iopsmallirplookasidelist
Lookaside "" # fffff80002a14800 "Irps"
Type = 0000 NonPagedPool
Current Depth = 0 Max Depth = 4
Size = 280 Max Alloc = 1120
AllocateMisses = 127 FreeMisses = 26
TotalAllocates = 190 TotalFrees = 90
Hit Rate = 33% Hit Rate = 71%
lkd> dt _general_lookaside fffff80002a14800 -b
ntdll!_GENERAL_LOOKASIDE
+0x000 ListHead : _SLIST_HEADER
+0x000 Alignment : 0x400001
+0x008 Region : 0xfffffa80`01e83b11
+0x000 Header8 : <unnamed-tag>
+0x000 Depth : 0y0000000000000001 (0x1)
+0x000 Sequence : 0y001000000 (0x40)
+0x000 NextEntry : 0y000000000000000000000000000000000000000 (0)
+0x008 HeaderType : 0y1
+0x008 Init : 0y0
+0x008 Reserved : 0y11111111111111111101010000000000000011110100000111011000100 (0x7fffea0007a0ec4)
+0x008 Region : 0y111
+0x000 Header16 : <unnamed-tag>
+0x000 Depth : 0y0000000000000001 (0x1)
+0x000 Sequence : 0y000000000000000000000000000000000000000001000000 (0x40)
+0x008 HeaderType : 0y1
+0x008 Init : 0y0
+0x008 Reserved : 0y00
+0x008 NextEntry : 0y111111111111111111111010100000000000000111101000001110110001 (0xfffffa8001e83b1)
+0x000 HeaderX64 : <unnamed-tag>
+0x000 Depth : 0y0000000000000001 (0x1)
+0x000 Sequence : 0y000000000000000000000000000000000000000001000000 (0x40)
+0x008 HeaderType : 0y1
+0x008 Reserved : 0y000
+0x008 NextEntry : 0y111111111111111111111010100000000000000111101000001110110001 (0xfffffa8001e83b1)
+0x000 SingleListHead : _SINGLE_LIST_ENTRY
+0x000 Next : 0x00000000`00400001
+0x010 Depth : 4
+0x012 MaximumDepth : 0x20
+0x014 TotalAllocates : 0xbe
+0x018 AllocateMisses : 0x7f
+0x018 AllocateHits : 0x7f
+0x01c TotalFrees : 0x5a
+0x020 FreeMisses : 0x1a
+0x020 FreeHits : 0x1a
+0x024 Type : 0 ( NonPagedPool )
+0x028 Tag : 0x73707249
+0x02c Size : 0x118
+0x030 AllocateEx : 0xfffff800`029c30e0
+0x030 Allocate : 0xfffff800`029c30e0
+0x038 FreeEx : 0xfffff800`029c30d0
+0x038 Free : 0xfffff800`029c30d0
+0x040 ListEntry : _LIST_ENTRY [ 0xfffff800`02a147c0 - 0xfffff800`02a148c0 ]
+0x000 Flink : 0xfffff800`02a147c0
+0x008 Blink : 0xfffff800`02a148c0
+0x050 LastTotalAllocates : 0xbe
+0x054 LastAllocateMisses : 0x7f
+0x054 LastAllocateHits : 0x7f
+0x058 Future :
[00] 0
[01] 0
lkd> !slist fffff80002a14800
SLIST HEADER:
+0x000 Header16.Sequence : 40
+0x000 Header16.Depth : 1
SLIST CONTENTS:
fffffa8001e83b10 0000000000000000 0000000000000000
0000000000000404 0000000000000000
Sorry if some of the formatting is lost. Essentially, this should be a lookaside list that contains a list of chunks that are all of the same size 0x118 (sizeof(_IRP) + sizeof(_IO_STACK_LOCATION))
However I'm not entirely sure how the list is actually put together, I'm not sure if this should be a singly linked list of memory chunks, or if I'm reading all of it incorrectly.
In case of small irp list with win7x86rtm:
lkd> !lookaside iopsmallirplookasidelist
Lookaside "" # 82d5ffc0 "Irps"
....
lkd> dt _SINGLE_LIST_ENTRY 82d5ffc0
nt!_SINGLE_LIST_ENTRY
+0x000 Next : 0x86737e30 _SINGLE_LIST_ENTRY
....
lkd> !pool 0x86737e30
Pool page 86737e30 region is Nonpaged pool
*86737e28 size: a0 previous size: 48 (Allocated) *Irp
Pooltag Irp : Io, IRP packets
The size of memory chank is a0 bytes
lkd> ?? sizeof(_pool_header)+sizeof(_single_list_entry)+sizeof(_irp)+sizeof(_io_stack_location)
unsigned int 0xa0
which include pool header, pointer, irp, stack location
Minor update:
Author Tarjei Mandt aka #kernelpool
In _GENERAL_LOOKASIDE structure, SingleListHead.Next points to the first free pool chunk on the singly-linked lookaside list. The size of the lookaside list is limited by the value of Depth, periodically adjusted by the balance set manager according to the number of hits and misses on the lookaside list. Hence, a frequently used lookaside list will have a larger Depth value than an infrequently used list. The intial Depth is 4 nt!ExMinimumLookasideDepth, with maximum being MaximumDepth (256)...more
SINGLE_LIST_ENTRY implements intrusive linked-lists. Look for struct list_head which offers similar functionnality within the linux kernel.
As for the .Next member, it really is a pointer to a SINGLE_LIST_ENTRY that is most likely embedded inside another struct.