Wai, I will also zero out the structure to be safe. But I assume the
initialization routine should do this for me. Or at the very least
initialize the structure to a usable state.
On Sun, May 7, 2017 at 10:05 PM Jamey Kirby wrote:
> That’s what I will check now. If it is not, I would consider this to be a
> bug in the StorPort stack. I assume the extension is allocated via
> ExAllocatePool(), and on 64 bit systems, this should be 16 byte aligned.
> But, I will check.
>
>
> On Sun, May 7, 2017 at 10:03 PM wrote:
>
>> Check if vhba_ext is aligned.
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: <
>> http://www.osronline.com/showlists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer>
>>
></http:>
FindAdapter gets adapter extension zero-initialized already.
FindAdapter can be called another time after STOP_DEVICE, but this time adapter extension carries the same state.
You may be assuming that the extension is allocated separately, but it isn’t - its memory is part of the same allocation used for the corresponding DEVICE_OBJECT, and has a 8-byte alignment - not necessarily the 16-byte alignment you are hoping for.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: 08 May 2017 03:06
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] RE : LookasideListEx alignment
That’s what I will check now. If it is not, I would consider this to be a bug in the StorPort stack. I assume the extension is allocated via ExAllocatePool(), and on 64 bit systems, this should be 16 byte aligned. But, I will check.
On Sun, May 7, 2017 at 10:03 PM > wrote:
Check if vhba_ext is aligned.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>
Well that would explain a lot.
On Mon, May 8, 2017 at 10:19 AM David Boyce wrote:
> You may be assuming that the extension is allocated separately, but it
> isn’t - its memory is part of the same allocation used for the
> corresponding DEVICE_OBJECT, and has a 8-byte alignment - not necessarily
> the 16-byte alignment you are hoping for.
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Jamey Kirby
> Sent: 08 May 2017 03:06
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] RE : LookasideListEx alignment
>
>
>
> That’s what I will check now. If it is not, I would consider this to be a
> bug in the StorPort stack. I assume the extension is allocated via
> ExAllocatePool(), and on 64 bit systems, this should be 16 byte aligned.
> But, I will check.
>
>
>
>
>
> On Sun, May 7, 2017 at 10:03 PM wrote:
>
> Check if vhba_ext is aligned.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at
>
>
> ------------------------------
> This email message has been delivered safely and archived online by
> Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
S. J. wrote:
I don?t think that 0xBEEF is a useful pool tag for pool tracking. According to
MSDN a pool tag is made of ASCII characters in the range 0x20 (space) to 0x126
Hmm hmm. A good point. IIRC bits 16 and 31 (0x8000 in 0xBEEF ) have some magic effects …
– pa
Yes, the following is a better choice:
(ULONG)‘FEEB’
J. S.
I gave numerous structures in my extension. Now, my extension contains just
a pointer to another allocated structure. This cleared up a couple of other
oddities in my driver.
On Mon, May 8, 2017, 6:24 PM xxxxx@outlook.com <
xxxxx@outlook.com> wrote:
Yes, the following is a better choice:
(ULONG)‘FEEB’
J. S.
NTDEV is sponsored by OSR
Visit the list online at: <
http://www.osronline.com/showlists.cfm?list=ntdev\>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>