Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


export bus driver of storport driver in crash dump

James_HarperJames_Harper Member Posts: 1,615
My virtual storport driver (xenvbd) is enumerated by a bus driver (xenpci), and is crashing when doing a dump. xenpci is an export driver too, exposing some calls used by xenvbd.

The stack trace shows that the bus driver is showing as 'dump_xenpci'. I haven't seen this before xenpci became an export driver... could this be why?

Is there an opportunity for dump_xenpci to initialize, prior to the crash dump? There is a global variable that contains the base address of the hypercall routines, and obviously if dump_xenpci has never been initialised then the hypercalls don't go anywhere useful.

Thanks

James

Comments

  • James,

    The explanation for dump_xenpci could be...
    --------
    http://blogs.technet.com/b/askperf/archive/2008/01/08/understanding-crash-dump-files.aspx
    Returning to the subject of how the dump file itself is generated, If a dump is
    configured, the system makes a copy of the disk miniport driver used to write to
    the boot volume in memory and prepends the driver name with "dump_".
    --------

    Although it says disk mini port, whereas in your case your bus driver is being considered.

    I cannot comment on this, but thought this might shed some light.

    Thanks,
    Arvind
  • Calvin_Guan-3Calvin_Guan-3 Member Posts: 441
    James,

    I don't have direct answer to your question. From what I read, xenpci is a
    driver that it creates devobjs, but also has functions exported (IAT
    section present pe header). If so, I'm wondering the dump path treats it as
    a DLL instead of a driver.

    A driver will be invoked at DriverEntry but an pure km DLL has
    DllInitialize as entry point. If you have both in a km PE, one and only one
    will get call depending on what system thinks it it. I would split the
    shared code from xenpci into a pure km DLL to make it cleaner.

    Calvin
    p.s. xen rocks. One day I would ask you how to put ubuntu srv on Dom0. I
    had several failed attempts by following some online how-to.


    On Sun, Dec 8, 2013 at 4:38 PM, James Harper
    wrote:

    > My virtual storport driver (xenvbd) is enumerated by a bus driver
    > (xenpci), and is crashing when doing a dump. xenpci is an export driver
    > too, exposing some calls used by xenvbd.
    >
    > The stack trace shows that the bus driver is showing as 'dump_xenpci'. I
    > haven't seen this before xenpci became an export driver... could this be
    > why?
    >
    > Is there an opportunity for dump_xenpci to initialize, prior to the crash
    > dump? There is a global variable that contains the base address of the
    > hypercall routines, and obviously if dump_xenpci has never been initialised
    > then the hypercalls don't go anywhere useful.
    >
    > Thanks
    >
    > James
    >
    > ---
    > NTDEV is sponsored by OSR
    >
    > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
    >
    > OSR is HIRING!! See http://www.osr.com/careers
    >
    > For our schedule of WDF, WDM, debugging and other seminars visit:
    > http://www.osr.com/seminars
    >
    > To unsubscribe, visit the List Server section of OSR Online at
    > http://www.osronline.com/page.cfm?name=ListServer
    >
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA