Saad Bashir wrote: > > i am developing a device upper filter driver for audio device that > will also save the streams passing through it. > to process the data , i am trying to intercept IRP_MJ_DEVICE_CONTROL > IRPs with following IoControl codes. > >IOCTL_KS_WRITE_STREAM >IOCTL_KS_READ_STREAM > > > I defined them as below. > >#define IOCTL_KS_READ_STREAM CTL_CODE(FILE_DEVICE_KS, 0x005, >METHOD_NEITHER, FILE_ANY_ACCESS) >#define IOCTL_KS_WRITE_STREAM CTL_CODE(FILE_DEVICE_KS, 0x004, >METHOD_NEITHER, FILE_WRITE_ACCESS) > > Why would you #define these yourself, instead of just adding #include <ks.h> in your driver? Isn't that where you copied these definitions from? > when i printed above devclared IOCTL_KS_READ_STREAM and recieved code > while debugging their values are printed as below > >declared IOCTL_KS_READ_STREAM code : 3080215 >recieved io control code: 3080195 > > > the recieved code is equal to as defined below with function code 0x000 > >CTL_CODE(FILE_DEVICE_KS, 0x000, METHOD_NEITHER, FILE_ANY_ACCESS) > > In the future, remember that ioctl codes and kernel status values are more easily understood when printed in hex. Let the computer do the work for you, instead of requiring an additional conversion step on your part. > where does the problem lies. What problem? Your filter will see ALL of the requests being handled by the lower-level driver. Kernel streaming drivers process many ioctls besides IOCTL_KS_READ_STREAM. > am i declaring IOCTL_KS_READ_STREAM with wrong function code ? No, but you shouldn't be defining it at all, since the definitions are available in an include file. Too much opportunity for error. > and recieved irp with above io control code corresponds to what??? A few minutes lookiing through the include files would have answered this question in much less time than sending a question to a mailing list. In ks.h, where you probably got those two definitions, we find: #define IOCTL_KS_PROPERTY CTL_CODE(FILE_DEVICE_KS, 0x000, METHOD_NEITHER, FILE_ANY_ACCESS) #define IOCTL_KS_ENABLE_EVENT CTL_CODE(FILE_DEVICE_KS, 0x001, METHOD_NEITHER, FILE_ANY_ACCESS) #define IOCTL_KS_DISABLE_EVENT CTL_CODE(FILE_DEVICE_KS, 0x002, METHOD_NEITHER, FILE_ANY_ACCESS) #define IOCTL_KS_METHOD CTL_CODE(FILE_DEVICE_KS, 0x003, METHOD_NEITHER, FILE_ANY_ACCESS) #define IOCTL_KS_WRITE_STREAM CTL_CODE(FILE_DEVICE_KS, 0x004, METHOD_NEITHER, FILE_WRITE_ACCESS) #define IOCTL_KS_READ_STREAM CTL_CODE(FILE_DEVICE_KS, 0x005, METHOD_NEITHER, FILE_READ_ACCESS) #define IOCTL_KS_RESET_STATE CTL_CODE(FILE_DEVICE_KS, 0x006, METHOD_NEITHER, FILE_ANY_ACCESS) You are seeing IOCTL_KS_PROPERTY. There will typically be hundreds of IOCTL_KS_PROPERTY requests before the stream data ever gets flowing. > i want to intercept IOCTL_KS_READ_STREAM and save the stream to ta > file in wave format. > am i following the correct approach? Probably not. How will you find out what format the stream is? (Note: you CAN find out, but it isn't necessarily easy.) What if it is compressed? What if the format changes in the middle? How are you going to know when to start and stop? I'm curious about what kind of data you hope to intercept. In most cases, it's better to do file access in user-mode. Are you intercepting in an application where you control the filter graph? Remember that the thread will be blocked while you do you write. > 2ndly if i get the data buffer through irp. what is the procedure to > save that data to file? Google for ZwCreateFile and ZwWriteFile. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.