[Vol-users] DPC procedure localization

BRTAN Jaroslav Jaroslav.BRTAN at firstdata.sk
Mon Jun 3 15:24:53 CDT 2013

Thanks both of you for your help and advice. I will try to verify if the memory is allocated. I have to convert the memory image to the crash dmp.
The --base switch works very well. I overlooked it in the help.

Od: "Michael Hale Ligh" <michael.hale at gmail.com<mailto:michael.hale at gmail.com>>
Datum: po, 6. 3, 2013 16:48
Předmět: [Vol-users] DPC procedure localization
Komu: "George M. Garner Jr." <ggarner_online at gmgsystemsinc.com<mailto:ggarner_online at gmgsystemsinc.com>>
Kopie: "vol-users" <vol-users at volatilityfoundation.org<mailto:vol-users at volatilityfoundation.org>>

Thanks for the explanation George!

Jaroslav - to answer your other question "how can I dump this using the
offset 0x80013000?" you can use the moddump plugin with --base= 0x80013000.


On Mon, Jun 3, 2013 at 10:43 AM, George M. Garner Jr. <
ggarner_online at gmgsystemsinc.com<mailto:ggarner_online at gmgsystemsinc.com>> wrote:

> Jaroslav,
> Kernel timers come and go at a very high rate which leads to a significant
> number of invalid or spurious timer artifacts which result from the fact
> that the memory dump was acquired from the system while it was running.
>  Not that the last two timers are signaled and the periods are not
> coherent.  It is possible that the last two "timer" objects reside in
> memory that once was a kernel timer object and has since been freed and
> that some of the timer fields (e.g. the routine address) have been
> overwritten with incoherent data.  Try running the !pool command on the
> last two timer addresses (0x863ead10 and 0x85e451e8) and see if that memory
> is currently allocated.  (I am assuming that you either have or can convert
> your memory dump to MS crashdump format.)
> Regards,
> George.
> On 6/3/2013 9:15 AM, BRTAN Jaroslav wrote:
>> Hi all,
>> I'd like to ask you for your help with analysis. The timers module shows
>> that there is a strange DPC at 0x8647e4e0.
>> Timers module output:
>> Offset(V)  DueTime                  Period(ms) Signaled   Routine
>>  Module
>> ---------- ------------------------ ---------- ---------- ----------
>> ------
>> 0x873097d0 0x0000002f:0x2db9d0c3             0 -          0xa7386d8e
>> arp1394.sys
>> 0x85b9a2c8 0x8000002d:0x6d7d7c8e             0 -          0x80538a98
>> ntoskrnl.exe
>> 0x8a332b20 0x0000002f:0x2ea5d991             0 -          0xb9ddef1a
>> NDIS.sys
>> 0x863ead10 0x00010014:0x863ead28    -205...072 Yes        0x8647e4e0
>> 0x85e451e8 0x00010014:0x85e45200    -205...072 Yes        0x8647e4e0
> ______________________________**_________________
> Vol-users mailing list
> Vol-users at volatilityfoundation.org<mailto:Vol-users at volatilityfoundation.org>
> http://lists.volatilesystems.**com/mailman/listinfo/vol-users<http://lists.volatilityfoundation.org/mailman/listinfo/vol-users>

The information in this message may be proprietary and/or confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify First Data immediately by replying to this message and deleting it from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.volatilityfoundation.org/pipermail/vol-users/attachments/20130603/c6d379da/attachment.html

More information about the Vol-users mailing list