Further Debugging Issues

WINDBG
1

For now I gave up on the dual boot machine and configured the machine I
could connect to for testing my driver. I seem to be having one problem
after another with my tools.

I’m just trying to get messages to display. When I was experimenting
with the remote debugger, I was able to get KdPrint messages to display
once, but I haven’t seen them since. I found DbgMon on OSR’s website
and I’m trying to get the messages to display there with a driver that I
know works with the hardware. It had KdPrint messages throughout.
Since the DbgMon documentation referred only to DbgPrint and DbgPrintEx
messages, I changed all the KdPrint messages to

DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_TRACE_LEVEL,“format string…”);

I run a mode that I know is triggering the driver (it turns on some
relays on the external hardware, so I can hear it). The code has
DbgPrintEx messages on all the I/O handling routines. I went into the
DbgMon event filter flags and set the DPFLTR_IHVDRIVER_ID flag to
DPFLTR_INFO_LEVEL and the check box for Enabled is checked.

Without message output I’m flying blind.

Additionally, I’ve been experimenting with the driver that won’t start
with OSR’s OSRLOADER program. I go to C:\Windows\System32\drivers and
select the MTIsaDrv.sys driver. The display name shows up as MTIsaDrv,
which is correct. I leave everything else as default. It registers OK
when I click on Register Service, but when I click on Start Service, it
pops up an error saying “The system cannot find the file specified.”
This is essentially the same problem I’ve been seeing when I tried to
load it programatically.

When the system calls Start Service, what happens with the driver? Is
this when DriverEntry is called? Why is it returning with file not
found? The OSR driver loader is obviously finding the file because I
browse for it in the driver directory. Under what conditions will a
driver return file not found?

The crazy thing is that a few days ago in a desperate attempt to get
something to work, I took the driver that was working, stripped out one
IOCTL call that was using some deprecated Ke386 function calls that
wasn’t being used anyway, then renamed the various variables and
function calls in the other driver to this driver’s names (ie replaced
all instances of porttalk or PortTalk with MTIsaDrv) and the behavior
didn’t change. The current version of the driver is 90% the same as the
old porttalk driver. The only differences are one less IOCTL case that
wasn’ used, the renaming of the variables, and some slight changes to
the CTL_CODE macros to generate different IOCTL numbers (I changed the
first argument from 40000 to 42000 only).

I still get the file not found error when I try to start the driver.

Is there something that is case sensitive that needs to be in all lower
case? That’s the only thing I can think of at this point.

Bill

2

“Bill Olson” wrote in message news:xxxxx@windbg…
…

> I’m just trying to get messages to display. When I was experimenting with
> the remote debugger, I was able to get KdPrint messages to display once,
> but I haven’t seen them since. I found DbgMon on OSR’s website

Do you use their last version? Just downloaded from their site?

> Additionally, I’ve been experimenting with the driver that won’t start
> with OSR’s OSRLOADER program. I go to C:\Windows\System32\drivers and
> select the MTIsaDrv.sys driver. The display name shows up as MTIsaDrv,
> which is correct. I leave everything else as default. It registers OK
> when I click on Register Service, but when I click on Start Service, it
> pops up an error saying “The system cannot find the file specified.” This
> is essentially the same problem I’ve been seeing when I tried to load it
> programatically.
>
> When the system calls Start Service, what happens with the driver? Is
> this when DriverEntry is called?

Yes

> Why is it returning with file not found? The OSR driver loader is
> obviously finding the file because I browse for it in the driver
> directory. Under what conditions will a driver return file not found?

a. The .sys file has unresolved imports.
Use dependency viewer (depends.exe) on the target machine to check this.
Aslo it can depend on kernel libraries (so called export drivers) that are
not present.

b. The .sys file is wrong for the target machine (like x64 driver on x86 OS
or a Win7 driver on XP)

c. DriverEntry() returns status that translates to “file not found”.

> The crazy thing is that a few days ago in a desperate attempt to get
> something to work, I took the driver that was working, stripped out one
> IOCTL call that was using some deprecated Ke386 function calls that wasn’t
> being used anyway, then renamed the various variables and function calls
> in the other driver to this driver’s names (ie replaced all instances of
> porttalk or PortTalk with MTIsaDrv) and the behavior didn’t change. The
> current version of the driver is 90% the same as the old porttalk driver.
> The only differences are one less IOCTL case that wasn’ used, the renaming
> of the variables, and some slight changes to the CTL_CODE macros to
> generate different IOCTL numbers (I changed the first argument from 40000
> to 42000 only).
>
> I still get the file not found error when I try to start the driver.

Well… sometimes things can go crazy; for this occasion one should
have an image backup ready. Or, find another clean machine.

> Is there something that is case sensitive that needs to be in all lower
> case? That’s the only thing I can think of at this point.

Do you build the driver with WDK, or with Visual Studio or something else?
Do you use external libraries besides of provided in WDK?

If you build with WDK, for correct target OS - any case
sensitivity issue, if any, will fail the build. When it builds ok, it should
load.

–pa

3

> “Bill Olson” wrote in message news:xxxxx@windbg…
>> I’m just trying to get messages to display. When I was experimenting
>> with the remote debugger, I was able to get KdPrint messages to
>> display once, but I haven’t seen them since. I found DbgMon on OSR’s
>> website

On 11/14/10 1:54 AM, Pavel A. wrote:
> Do you use their last version? Just downloaded from their site?

Downloaded a little over 24 hours ago from their site.

>> Additionally, I’ve been experimenting with the driver that won’t start
>> with OSR’s OSRLOADER program. I go to C:\Windows\System32\drivers and
>> select the MTIsaDrv.sys driver. The display name shows up as MTIsaDrv,
>> which is correct. I leave everything else as default. It registers OK
>> when I click on Register Service, but when I click on Start Service,
>> it pops up an error saying “The system cannot find the file
>> specified.” This is essentially the same problem I’ve been seeing when
>> I tried to load it programatically.
>>
>> When the system calls Start Service, what happens with the driver? Is
>> this when DriverEntry is called?
>
> Yes
>
>> Why is it returning with file not found? The OSR driver loader is
>> obviously finding the file because I browse for it in the driver
>> directory. Under what conditions will a driver return file not found?
>
> a. The .sys file has unresolved imports.
> Use dependency viewer (depends.exe) on the target machine to check this.
> Aslo it can depend on kernel libraries (so called export drivers) that
> are not present.

I ran depends.exe on the development machine, but not the target. There
probably is something missing that it needs…

> b. The .sys file is wrong for the target machine (like x64 driver on x86 OS
> or a Win7 driver on XP)

The target is XP x86 and I set the target to that in sources and set it
to build x86 code. All OSes on all computers involved are 32 bit. 64
bit is not a requirement.

> c. DriverEntry() returns status that translates to “file not found”.

I guess it is. I wish I could figure out how to get the messages from
the driver. Without them, I’m shooting in the dark.

>> The crazy thing is that a few days ago in a desperate attempt to get
>> something to work, I took the driver that was working, stripped out
>> one IOCTL call that was using some deprecated Ke386 function calls
>> that wasn’t being used anyway, then renamed the various variables and
>> function calls in the other driver to this driver’s names (ie replaced
>> all instances of porttalk or PortTalk with MTIsaDrv) and the behavior
>> didn’t change. The current version of the driver is 90% the same as
>> the old porttalk driver. The only differences are one less IOCTL case
>> that wasn’ used, the renaming of the variables, and some slight
>> changes to the CTL_CODE macros to generate different IOCTL numbers (I
>> changed the first argument from 40000 to 42000 only).
>>
>> I still get the file not found error when I try to start the driver.
>
> Well… sometimes things can go crazy; for this occasion one should
> have an image backup ready. Or, find another clean machine.

I can reinstall on this system if I need to. It was built for debugging
drivers expecting that I would probably mess it up a few times during
development.

>> Is there something that is case sensitive that needs to be in all
>> lower case? That’s the only thing I can think of at this point.
>
> Do you build the driver with WDK, or with Visual Studio or something else?
> Do you use external libraries besides of provided in WDK?

I build with the latest WDK and no external libraries.

> If you build with WDK, for correct target OS - any case
> sensitivity issue, if any, will fail the build. When it builds ok, it
> should load.

I know Unix/Linux is very case dependent, but the Microsoft world tends
to be insensitive to case.

I think there may be a dependency issue. I’ll try running depends and
see if it turns up anything.

Thanks,
Bill

4

Found the problem. The driver is written as a WDM driver, but there was
a command in the sources file to compile it as a WDF and the WDF helped
sys file was missing. Removed the line in the sources file and it works
now.

Thanks,
Bill

On 11/14/10 4:55 AM, Bill Olson wrote:

> “Bill Olson” wrote in message news:xxxxx@windbg…
>>> I’m just trying to get messages to display. When I was experimenting
>>> with the remote debugger, I was able to get KdPrint messages to
>>> display once, but I haven’t seen them since. I found DbgMon on OSR’s
>>> website
>
> On 11/14/10 1:54 AM, Pavel A. wrote:
>> Do you use their last version? Just downloaded from their site?
>
> Downloaded a little over 24 hours ago from their site.
>
>>> Additionally, I’ve been experimenting with the driver that won’t start
>>> with OSR’s OSRLOADER program. I go to C:\Windows\System32\drivers and
>>> select the MTIsaDrv.sys driver. The display name shows up as MTIsaDrv,
>>> which is correct. I leave everything else as default. It registers OK
>>> when I click on Register Service, but when I click on Start Service,
>>> it pops up an error saying “The system cannot find the file
>>> specified.” This is essentially the same problem I’ve been seeing when
>>> I tried to load it programatically.
>>>
>>> When the system calls Start Service, what happens with the driver? Is
>>> this when DriverEntry is called?
>>
>> Yes
>>
>>> Why is it returning with file not found? The OSR driver loader is
>>> obviously finding the file because I browse for it in the driver
>>> directory. Under what conditions will a driver return file not found?
>>
>> a. The .sys file has unresolved imports.
>> Use dependency viewer (depends.exe) on the target machine to check
>> this.
>> Aslo it can depend on kernel libraries (so called export drivers) that
>> are not present.
>
> I ran depends.exe on the development machine, but not the target. There
> probably is something missing that it needs…
>
>> b. The .sys file is wrong for the target machine (like x64 driver on
>> x86 OS
>> or a Win7 driver on XP)
>
> The target is XP x86 and I set the target to that in sources and set it
> to build x86 code. All OSes on all computers involved are 32 bit. 64 bit
> is not a requirement.
>
>> c. DriverEntry() returns status that translates to “file not found”.
>
> I guess it is. I wish I could figure out how to get the messages from
> the driver. Without them, I’m shooting in the dark.
>
>>> The crazy thing is that a few days ago in a desperate attempt to get
>>> something to work, I took the driver that was working, stripped out
>>> one IOCTL call that was using some deprecated Ke386 function calls
>>> that wasn’t being used anyway, then renamed the various variables and
>>> function calls in the other driver to this driver’s names (ie replaced
>>> all instances of porttalk or PortTalk with MTIsaDrv) and the behavior
>>> didn’t change. The current version of the driver is 90% the same as
>>> the old porttalk driver. The only differences are one less IOCTL case
>>> that wasn’ used, the renaming of the variables, and some slight
>>> changes to the CTL_CODE macros to generate different IOCTL numbers (I
>>> changed the first argument from 40000 to 42000 only).
>>>
>>> I still get the file not found error when I try to start the driver.
>>
>> Well… sometimes things can go crazy; for this occasion one should
>> have an image backup ready. Or, find another clean machine.
>
> I can reinstall on this system if I need to. It was built for debugging
> drivers expecting that I would probably mess it up a few times during
> development.
>
>>> Is there something that is case sensitive that needs to be in all
>>> lower case? That’s the only thing I can think of at this point.
>>
>> Do you build the driver with WDK, or with Visual Studio or something
>> else?
>> Do you use external libraries besides of provided in WDK?
>
> I build with the latest WDK and no external libraries.
>
>> If you build with WDK, for correct target OS - any case
>> sensitivity issue, if any, will fail the build. When it builds ok, it
>> should load.
>
> I know Unix/Linux is very case dependent, but the Microsoft world tends
> to be insensitive to case.
>
> I think there may be a dependency issue. I’ll try running depends and
> see if it turns up anything.
>
> Thanks,
> Bill
>
> —
> WINDBG 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
>