Author Topic: Microsoft WDK Filter Manager definitions  (Read 10317 times)

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Microsoft WDK Filter Manager definitions
« on: November 08, 2010, 11:20:34 pm »
I'm having trouble seeing certain function declarations exposed in %WDKPATH%\inc\ddk\fltKernel.h from the most recent Windows Driver Kit (7600.16385.1).  I have a brand-spanking new installation of SE 15.0.1.3 with hotfix_loader_se15013_3 and hotfix_se1501_10_cumulative rev 10 installed.
To reproduce the problem:

  • install the WDK
  • create a new compiler by putting %WDKPATH%\inc in the "Built-in Compiler Include Directories", and use vcpp.h as the optional header
  • While that's tagging in the background (love the background tagging!   :D), create a new "Other C/C++" project in %WDKPATH%\src\filesys\minifilter\minispy
  • use Add Tree to add the default c/c++ file types, select the WDK compiler you created, and then close the new project dialog
  • Open minispy.c, go to the SpyPreOperationCallback routine
  • try to get the definition of FltGetFileNameInformation
After doing all that, that tag isn't found.  I've attached my workspace/project just in case it's something local I did without realizing it.
I have tried adding some of the definitions that might be getting in the way of conditional code, such as NTDDI_VERSION and FLT_MGR_BASELINE to the preprocessing defines, that didn't correct the problem.
« Last Edit: November 08, 2010, 11:40:32 pm by Phil Barila »

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Microsoft WDK Filter Manager definitions
« Reply #1 on: November 08, 2010, 11:50:41 pm »
Hi Phil,
maybe this solves your problem.
Since I started KMDF development using SE v12 I'm using these add-ons to usercpp.h (SE C/C++ Preprocessing):
Code: [Select]
#define __drv_functionClass(fc)           fc
#define __drv_sameIRQL
#define __drv_maxIRQL(maxIRQL)

Most other SAL macros are finally specified with something SE knows about like __checkReturn (see sal.h)
And it seems that this still applies to WDK7600.16385.1 (I'm using too).

FltGetFileNameInformation is tagged correctly here.

I've also specified each 'inc' subdir (I probably need) separately.
I think the compiler includes are not scanned recursively.
At least I had to do that in the past and since that time I'm just patching new WDK versions directly in 'compilers.xml'..
Example:
Code: [Select]
<C_Configuration Name="WDK 7600.16385.1 - KMDF 1.9" Header="sysconfig\vsparser\vscpp.h">
<Includes>
<Include Dir="C:\WDK\7600.16385.1\inc\" />
<Include Dir="C:\WDK\7600.16385.1\inc\api\" />
<Include Dir="C:\WDK\7600.16385.1\inc\api\crt\stl70\" />
<Include Dir="C:\WDK\7600.16385.1\inc\atl71\" />
<Include Dir="C:\WDK\7600.16385.1\inc\crt\" />
<Include Dir="C:\WDK\7600.16385.1\inc\crt\gl\" />
<Include Dir="C:\WDK\7600.16385.1\inc\crt\sys\" />
<Include Dir="C:\WDK\7600.16385.1\inc\ddk\" />
<Include Dir="C:\WDK\7600.16385.1\inc\mfc42\" />
<Include Dir="C:\WDK\7600.16385.1\inc\wdf\kmdf\1.9\" />
<Include Dir="C:\WDK\7600.16385.1\lib\" />
</Includes>
</C_Configuration>
Good luck, HS2

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Microsoft WDK Filter Manager definitions
« Reply #2 on: November 09, 2010, 12:21:48 am »
HS2 comes through again!   :)  HP++  It was only one bogus definition that was causing the problem.
Code: [Select]
__drv_functionClasswas defined without a parameter.  I deleted the def, then added it, and it automagically offered to define:
Code: [Select]
__drv_functionClass    __drv_out(__drv_declspec("SAL_functionClass(\""#x "\")"))I accepted that, and as soon as I rebuilt the tag file, lots of FltXyz functions were suddenly tagged.  I assume that because adding the single include path results in all the headers being included in the tag file, it is also tagging them.  :)

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Microsoft WDK Filter Manager definitions
« Reply #3 on: November 09, 2010, 01:34:32 am »
Oh my - it's long ago when I set up my KMDF environment...
But now I remember .. I intentionally specified each path in the compiler setup because this list is inherited by projects using this compiler. So they are auto-added to the Project Properties > Directories and I didn't need to manually add them for other projects.
Alternatively you could create a customized C/C++ KMDF project type and add the default %WDKPATH%\inc dirs which is also fine.
Maybe the latter is bit smarter when migrating to new WDK versions. But fortunately this happens not very often ;)

HS2

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Microsoft WDK Filter Manager definitions
« Reply #4 on: November 11, 2010, 09:24:58 pm »
I've discovered why you did all the directories, instead of just one.  Although all the files are recursively tagged, so symbols in the files are found OK, the filename in an #include<> are not found unless the directory in which the file resides is in the directory list.  Sure is a pain to add all those directories with the browser, since that list box doesn't support typing in a new line.

Phil Barila

  • Senior Community Member
  • Posts: 742
  • Hero Points: 61
Re: Microsoft WDK Filter Manager definitions
« Reply #5 on: November 12, 2010, 06:26:28 pm »
Just for the sake of completeness, I also needed to delete the empty definition of:
Code: [Select]
__checkReturn and add it in again, selecting the alternative offered:
Code: [Select]
checkReturn __inner_checkReturn and then add the missing:
Code: [Select]
__inner_checkReturn and accept the offered:
Code: [Select]
__inner_checkReturn __declspec("SAL_checkReturn")

hs2

  • Senior Community Member
  • Posts: 2752
  • Hero Points: 291
Re: Microsoft WDK Filter Manager definitions
« Reply #6 on: November 12, 2010, 11:19:01 pm »
Thanks Phil !
Strange enough - my legacy SE CPP tuning still works (somehow). I didn't need to define __checkReturn.
However, I'll keep that in mind. - HS2