[NOOB] [FILTER DRIVER] problem setting flag after iocreatedevice

Aarggh-

>
You also have source code for your replacement driver as well as the app you are attempting to reverse engineer- thus a complete solution with no missing source (except for the Windows I/O manager and HAL, anyway) and no mysteries.
<<

That should have been prefaced with “After you reverse engineer the application using these logs”…

Point being one logging vehicle is as good as the other, and there’s probably more value in a quick and dirty replacement if you can get it than in a filter.

Yes you’re right.

I just want to precise again that i’m not a natural born reverse engineer.
If i was a reverse engineer i probably just fire a debugger and patch the userland .exe with a log function.

And paradoxically the fact i’m not (yet) able to do such a thing drives me in kernland.

And, ho… sorry but i’m not sure to understand “Point being one logging vehicle is as good as the other, and there’s probably more value in a quick and dirty replacement if you can get it than in a filter.”

Did you mean i’m wasting time writing a filter?

In fact i’m agree for job purpose, i’ll study portio and it’s more valuable:

  1. i will be able to replace in my own programs smport by portio. And i’ll have all source of the solution with no mistery and as smport seems to be no longer supported by anyone, it’s a very good thing.

  2. i will be able to modify the driver in the way i want to… In this case i probably will able to finally know what to send where in a very short time.

Finish the filter driver is now only for educationnal purpose. And also because i really don’t like to begin something and give up.

JOKE: Another good reason is that windows XP is now very stable and i have the nostalgy of B.S.O.D. , since i began to code my filter driver (and also some other basic drivers) my computer is always blue!

KMDF also seems to be a great help.

So thank’s again all.

Ho i have a question for you bob and doron. Are you really microsoft coders?
it really seems in fact.
Woaa, it’s great.
Are you in redmond? Is it cool?
Sorry i’m like a kid… But well you know… Microsoft!

There are good reasons for doing a filter- but some people just want to be done as soon as they can, in which case you could say it is a waste IF the other method works [if portio doesn’t get you close to done, then IT would be a waste of time- the amount of time in one case is a lot smaller than the other is all].

By all means do it if you want the knowledge, and KMDF should be a very useful tool both to use and to learn [but I do have some stake in it, to be fair].

As for the rest…

Doron and I are developers in roughly the same group- except he’s much more important ;). I’ll tell you a bit about each of us (mostly about myself, of course)…

He is a key person (sort of a super-programmer :wink: in the development of KMDF and UMDF (if he wants to explain what he does, I’ll leave that to him- his blog on MSDN has a short bio).

I am part of the team that is responsible for QA for KMDF and UMDF- so I have to find Doron’s bugs [hopefully before you do], figure out what people do and don’t like about WDF (quality has many meanings), and see if there are things we can do to “fix” some of the “don’t likes” [for instance, by providing better tools, more samples, or documentation].

Most of my work is test software which isn’t shipped, although we produce an occasional tool or sample (in the latest beta WDK [not the one you are using, though], WdfVerifier is my opus, while one of my colleagues contributed the new KMDF HID minidriver sample (treats OSR USBFX2 as a HID device), and soon a new testing tool called WdfTester [all discussed at the recent WinHEC]).

We are both in Redmond (same building and floor, but different wings of the building- maybe 30-40 meters apart)- assuming cool didn’t mean temperature, I believe we both like working here. If you meant temperature, well we’re pretty far north (for the USA, anyway), near an ocean with a cold-water current flowing offshore, so it is usually pretty cool…

Good luck with your project, and thanks for the kind words. If you have problems with KMDF, we’re interested in knowing about them…

My conscience is bothering me a bit after my last post (should have used email, since this sort of thing is off-topic), so I hasten to add:

Doron and I and several others from Microsoft post here voluntarily. So do the non-Microsoft people. Don’t assume because the advice didn’t come from an @microsoft.com address that it is necessarily inferior- some of the best information I’ve found on this list came from those folks. I’d be the first to say many of them are more “expert” than I am.

That’s definitely part of what makes this list such a good resource.

[TOPIC CLOSED] <— i thinkit’s time.

Yes, you’re right, and i thank’s Tim Roberts too for the help. And to finish, all this forum is a great support and the global skill level is very very good.

[REOPENING THE TOPIC]

ouch, well i try to compile a version of portio with new values to match one of my basic delphi app
(just reading the LPT1 port)

So that’s what i modify in gpioctl.h

#define GPD_TYPE 61696
// The IOCTL function codes from 0x800 to 0xFFF are for customer use.

#define IOCTL_GPD_READ_PORT_UCHAR \
CTL_CODE( GPD_TYPE, 0x901, METHOD_BUFFERED, FILE_READ_ACCESS )

#define IOCTL_GPD_WRITE_PORT_UCHAR \
CTL_CODE(GPD_TYPE, 0x902, METHOD_BUFFERED, FILE_WRITE_ACCESS)

#define IOCTL_GPD_READ_PORT_USHORT \
CTL_CODE( GPD_TYPE, 0x903, METHOD_BUFFERED, FILE_READ_ACCESS )

#define IOCTL_GPD_WRITE_PORT_USHORT \
CTL_CODE(GPD_TYPE, 0x904, METHOD_BUFFERED, FILE_WRITE_ACCESS)

#define IOCTL_GPD_READ_PORT_ULONG \
CTL_CODE( GPD_TYPE, 0x905, METHOD_BUFFERED, FILE_READ_ACCESS )

#define IOCTL_GPD_WRITE_PORT_ULONG \
CTL_CODE(GPD_TYPE, 0x916, METHOD_BUFFERED, FILE_WRITE_ACCESS)

TARGETNAME=smport in SOURCES

of course it compiles fine.

So i put the .sys in my app directory instead of the old one.

fire up my app.
The app Install the driver. And then try to start the service and… Failed to start it.

So i use a little programm to uninistall the driver.
OK

Fire up DebugView, and i my installer/starter.
InstDriver -Install smport smport.sys
smport succesfully installed.
InstDriver -Start smport
Failed to start.
InstDriver -Uninstall smport
smport succesfully Uninstalled.

here’s the bebug output from DebugView

PortIo:
Entered Driver Entry
PortIo:
unload

So for the next test i compile the original gpio driver without any modification.
No problem
Fireup debugview

InstDriver -Install genport genport.sys
smport succesfully installed.
InstDriver -genport smport
Failed to start.

the bebug output from DebugView is exactly the same

PortIo:
Entered Driver Entry
PortIo:
unload

By the way i tried to install the driver manually once again…
Successfull
and fireup

GpdRead -b 1
Unable to open the Device.
Ouch…

So i decided to use the “add hardware” wizzard
everything runs fine
GpdRead -b 1
Ioctl failed with code 87

That’s etter even if it’s not really a big succes.

So i’ll try ro use the add hadware wizzard to install the “new” replacement smport driver to test with my app.

I assume i also have to modify

%PortIO.DRVDESC%=PortIO_Inst,root\portio

by

%PortIO.DRVDESC%=PortIO_Inst,root\smport

(I’m not very familiar yet with .inf)

The fact is smport does not use .inf

What i don’t understand is why when i manually install the driver i can’t start it.
here’s the (yes i know it’s pascal syntax but api call is api call) the code for my installer

procedure TSmallPort.InstallSmallPortDriver;
var
hService: SC_HANDLE;
DriverPath: string;
buf: array[0…MAX_PATH - 1]of char;
begin
dwLastError := 0;
DriverPath := GetCurrentDir + '' + DriverName + ‘.sys’;
if not FileExists(DriverPath)then
begin
GetSystemDirectory(buf, MAX_PATH);
DriverPath := StrPas(buf) + '' + DriverName + ‘.sys’;
end;
hService := CreateService(hManager, PChar(DriverName),PChar(DriverName),
SERVICE_ALL_ACCESS,
SERVICE_KERNEL_DRIVER,
SERVICE_DEMAND_START,
SERVICE_ERROR_NORMAL,
PChar(DriverPath),
nil, nil, nil, nil, nil);
if hService = 0 then dwLastError := GetLastError
else
begin
CloseServiceHandle(hService);
dwLastError := 0;
end;
end;

The big part is CreateService api call. And it seems correct to me.
But as you know all errors seem to be correct to the eyes of the coder.

Well i can verify the fact the driver is installed after the call but…

The problem is that smport is based upon the NT4 version of the portio sample, which can be installed as a service. The version in the later DDKs and the WDK is a plug-and-play root enumerated driver with an INF.

It did occur to me last evening that this would probably be the case (actually, it was pretty likely, because it’s an old driver, and this is a much simpler installation method than the INF-based one).

I don’t know if the NT 4 DDK is available any longer (I threw away my last copies a couple months back while moving).

Assuming it isn’t, I’ll tell you how to fix the driver to roll it back to legacy level. I’ll email that to you, in sufficient detail that you should be able to get there.

As for why emailing it, I believe most people on the list could do this with half their brain tied behind their back, and would find the post annoying.

Yes you are right it’s a legacy driver.
thank you for for the help, i will wait for the mail without posting. Ok?
Sorry for all the people able to do this with only half a brain.
Mine is not trained to this type of gymnastic.
May be a day…

Having just read this thread, this was my thought - Delphi? no problems.
But ask about C++…

mm

>> xxxxx@probo.com 2007-05-24 15:41 >>>
xxxxx@gmail.com wrote:
I want to thank you all again.
You are an incredible great support for me.

It’s amazing.

Ah, you got lucky. We usually string up the newbies and feed them to
the lions. :wink:

Just don’t ask about C++…


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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer