custom debug host driver

Sorry, folks!

Thomas

>

James Harper wrote:
> How does one make a kernel mode dll?
>
> TARGETTYPE=DYNLINK is for a user mode dll and so the build
environment
> isn’t set up right for kernel mode
> TARGETTYPE=EXPORT_DRIVER builds a .sys, and appears to ignore
TARGETEXT
> TARGETTYPE=GDI_DRIVER appears to want to link with win32k.sys which
> maybe I don’t want?
>
> Should I build my EXPORT_DRIVER .sys file and just rename it?

Use EXPORT_DRIVER and just leave its name as .sys. There’s no reason
to
change it. In my mind, .dll implies a user-mode DLL.

I’m not confident that kd will find it though. I can see no reason why
/DEBUGPORT=xen would load anything other than
C:\WINDOWS\system32\kdxen.dll… do you really think it would be smart
enough to also look for kdxen.sys?

James

I’m going to go with no.

Mm

On Oct 18, 2010 8:33 PM, “James Harper”
wrote:
>>
>> James Harper wrote:
>> > How does one make a kernel mode dll?
>> >
>> > TARGETTYPE=DYNLINK is for a user mode dll and so the build
> environment
>> > isn’t set up right for kernel mode
>> > TARGETTYPE=EXPORT_DRIVER builds a .sys, and appears to ignore
> TARGETEXT
>> > TARGETTYPE=GDI_DRIVER appears to want to link with win32k.sys which
>> > maybe I don’t want?
>> >
>> > Should I build my EXPORT_DRIVER .sys file and just rename it?
>>
>> Use EXPORT_DRIVER and just leave its name as .sys. There’s no reason
> to
>> change it. In my mind, .dll implies a user-mode DLL.
>>
>
> I’m not confident that kd will find it though. I can see no reason why
> /DEBUGPORT=xen would load anything other than
> C:\WINDOWS\system32\kdxen.dll… do you really think it would be smart
> enough to also look for kdxen.sys?
>
> James
>
> —
> NTDEV is sponsored by OSR
>
> 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

I’d wondered this too. Never got round to trying it, but the build
documentation implies setting USE_LIBCNTPR = 1 might allow one to
build a kernel DLL. I could be barking up the wrong tree though.
I don’t think renaming an export driver will work; the entry point(s)
are not the same so I can’t see how the linkage would work.

Paul

On 17 October 2010 05:21, James Harper wrote:
> How does one make a kernel mode dll?
>
> TARGETTYPE=DYNLINK is for a user mode dll and so the build environment
> isn’t set up right for kernel mode
> TARGETTYPE=EXPORT_DRIVER builds a .sys, and appears to ignore TARGETEXT
> TARGETTYPE=GDI_DRIVER appears to want to link with win32k.sys which
> maybe I don’t want?
>
> Should I build my EXPORT_DRIVER .sys file and just rename it?
>
> Thanks
>
> James
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:bounce-428120-
>> xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
>> Sent: Sunday, 17 October 2010 14:08
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] custom debug host driver
>>
>> I believe that it uses polling.
>>
>>
>> Good luck,
>>
>> mm
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of James Harper
>> Sent: Saturday, October 16, 2010 11:06 PM
>> To: Windows System Software Devs Interest List
>> Subject: RE: [ntdev] custom debug host driver
>>
>> >
>> > Officially, no, the KdStubs interface is not documented, but it’s
>> possible.
>> >
>> > You might want to take a look at VirtualKD
>> (http://virtualkd.sysprogs.org/)
>> > and VirtualBox (http://www.virtualbox.org/).
>> >
>> > In particular, VirtualKD’s KDVM implements a custom kd transport.
>> >
>>
>> Nice. So I can write my own kdxen.dll and then say /debugport=xen -
> it’s
>> almost too easy :slight_smile:
>>
>> Do you know if the kd dll uses interrupts or is it purely polled? I’ve
> had a
>> quick look in kdcom.dll and can’t see where an irq would be set, but
> by its
>> very nature it would operate as close to the hardware as possible and
> so
>> wouldn’t use normal ‘give me an irq’ methods…
>>
>> Thanks!
>>
>> James
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> 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
>
> —
> NTDEV is sponsored by OSR
>
> 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
>


Paul Durrant
http://www.linkedin.com/in/pdurrant

>

I’d wondered this too. Never got round to trying it, but the build
documentation implies setting USE_LIBCNTPR = 1 might allow one to
build a kernel DLL. I could be barking up the wrong tree though.
I don’t think renaming an export driver will work; the entry point(s)
are not the same so I can’t see how the linkage would work.

Building an export driver and renaming it works just fine, at least in
the case of kd modules.

James

The following may be of interest in addition to the two previously mentioned
links:

http://articles.sysprogs.org/kdvmware/kdcom.shtml.

Regards,

George.

“M. M. O’Brien” wrote in message
news:xxxxx@ntdev…
> Officially, no, the KdStubs interface is not documented, but it’s
> possible.
>
> You might want to take a look at VirtualKD
> (http://virtualkd.sysprogs.org/)
> and VirtualBox (http://www.virtualbox.org/).
>
> In particular, VirtualKD’s KDVM implements a custom kd transport.
>
>

Paul Durrant wrote:

I’d wondered this too. Never got round to trying it, but the build
documentation implies setting USE_LIBCNTPR = 1 might allow one to
build a kernel DLL.

That’s irrelevant. USE_LIBCNTPR merely determines whether the driver
will link with the kernel C run-time library. There’s really nothing
special about a kernel DLL. All drivers can have exports.

I could be barking up the wrong tree though.
I don’t think renaming an export driver will work; the entry point(s)
are not the same so I can’t see how the linkage would work.

The entry points are the same. What would lead you to think they aren’t?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.