FEED Validator

for Atom and RSS and KML

Sorry

This feed does not validate.

line 423, column 175: XML parsing error: <unknown>:423:175: not well-formed (invalid token) [help]

... stallDriverPackages,CustomActionData=2.15{8C64E674-5476-46E4-93CD-BA1A ...
                                             ^

Source: http://kobyk.wordpress.com/feed/

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
>
<channel>
<title>KK's Blog</title>
<atom:link href="https://kobyk.wordpress.com/feed/" rel="self" type="application/rss+xml" />
<link>https://kobyk.wordpress.com</link>
<description>I don't have to put up with this shit...</description>
<lastBuildDate>Sat, 26 Nov 2011 09:04:25 +0000</lastBuildDate>
<language>en</language>
<sy:updatePeriod>
hourly </sy:updatePeriod>
<sy:updateFrequency>
1 </sy:updateFrequency>
<generator>http://wordpress.com/</generator>
<cloud domain='kobyk.wordpress.com' port='80' path='/?rsscloud=notify' registerProcedure='' protocol='http-post' />
<image>
<url>https://s0.wp.com/i/buttonw-com.png</url>
<title>KK's Blog</title>
<link>https://kobyk.wordpress.com</link>
</image>
<atom:link rel="search" type="application/opensearchdescription+xml" href="https://kobyk.wordpress.com/osd.xml" title="KK's Blog" />
<atom:link rel='hub' href='https://kobyk.wordpress.com/?pushpress=hub'/>
<item>
<title>Modifying a Visual C++ 2010 project’s Platform Toolset programmatically with IVCRulePropertyStorage</title>
<link>https://kobyk.wordpress.com/2011/11/26/modifying-a-visual-c-2010-projects-platform-toolset-programmatically-with-ivcrulepropertystorage/</link>
<comments>https://kobyk.wordpress.com/2011/11/26/modifying-a-visual-c-2010-projects-platform-toolset-programmatically-with-ivcrulepropertystorage/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Sat, 26 Nov 2011 09:04:25 +0000</pubDate>
<category><![CDATA[C++]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=56</guid>
<description><![CDATA[Back from a long hiatus. Lately I’ve been migrating a large legacy code base from Visual C++ 2008 to Visual C++ 2010. Visual C++ 2010 supports Native Multi-Targeting, which lets you use the Visual Studio 2010 IDE and the new … <a href="https://kobyk.wordpress.com/2011/11/26/modifying-a-visual-c-2010-projects-platform-toolset-programmatically-with-ivcrulepropertystorage/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[Back from a long hiatus.
Lately I’ve been migrating a large legacy code base from Visual C++ 2008 to Visual C++ 2010. Visual C++ 2010 supports Native <a title="C++ Native Multi-Targeting" href="http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx">Multi-Targeting</a>, which lets you use the Visual Studio 2010 IDE and the new MSBuild-based C++ project system (*.vcxproj files, etc.) while invoking a legacy compiler like Visual C++ 2008 for the actual build, or for invoking the modern compiler with special INCLUDE and LIB directory settings (e.g., using the Windows Driver Kit’s headers and import libraries).
The “Platform Toolset” is the project setting which specifies which baseline compiler settings apply. Visual Studio 2010 bundles the “v100” platform toolset for using the Visual C++ 2010 compiler and the “v90” platform toolset for using the Visual C++ 2008 compiler. The Windows SDK 7.1 includes the “Windows7.1SDK” platform toolset which invokes the Visual C++ 2010 compiler, but with the SDK’s build environment. The latest Intel C++ Compiler includes a “Intel C++ Compiler XE 12.0” toolset, as well. A third party has even created a<a title="VS2003 Platform Toolset for VS2010" href="http://vs2003.blogspot.com/"> platform toolset for the antiquated Visual C++ 2003 compiler</a>.
The IDE GUI exposes the Platform Toolset project setting in the General property sheet. By right clicking a project in Solution Explorer, clicking Properties and going to General under Configuration Properties, you can change the setting on a per-build configuration basis. Solution Explorer is clever enough to let you group select several or all of the projects in the open solution and group-modifying the platform toolset in the properties dialog. For many cases, this may be sufficient.
However, if you want to modify the platform toolset en masse, but based on more complicated criteria, or just wish to achieve a higher degree of automation in the migration process, you may prefer to modify the setting programmatically like I did.
Visual Studio has an automation model for modifying project settings and for many other IDE tasks. This object model is accessible from Visual Studio Macros (which have unfortunately been removed from the Visual Studio 11 Developer Preview) and from other forms of Visual Studio extensibility such as add-ins. After some browsing of the documentation and searching the Web, it is clear how to modify things like the project’s Linker OutputFile property. However, it took me a while to figure out how to access other properties like the PlatformToolset.
It turns out that project settings that have appeared recently are not accessible in straightforward way like the older ones. That is, they are not properties of the VCProject object or its child objects. Instead, <a title="How to read/write the new Visual C++ project properties" href="http://blogs.msdn.com/b/visualstudio/archive/2010/01/15/how-to-read-write-the-new-visual-c-project-properties.aspx">there is a new interface</a> for manipulating these properties, <a title="IVCRulePropertyStorage" href="http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.vcprojectengine.ivcrulepropertystorage.aspx">IVCRulePropertyStorage</a>.
With this interface, the PlatformToolset property in the General property sheet becomes easily accessible. To illustrate, the following is an example Visual Studio macro that changes the platform toolset of any project in the solution using the “v100” toolset to the “Windows7.1SDK” toolset:
<pre class="brush: vb; title: ; wrap-lines: false; notranslate">
Option Strict On
Option Explicit On
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics
Imports Microsoft.VisualStudio.VCProject
Imports Microsoft.VisualStudio.VCProjectEngine
Public Module Module1
Sub RetargetProjects()
For Each p As Project In DTE.Solution.Projects
If p.Kind = vcContextGuids.vcContextGuidVCProject Then
Dim prj As VCProject = CType(p.Object, VCProject)
For Each cfg As VCConfiguration In CType(prj.Configurations, IVCCollection)
Dim generalRule As IVCRulePropertyStorage = CType(cfg.Rules.Item("ConfigurationGeneral"), IVCRulePropertyStorage)
Dim currentPlatformToolset = generalRule.GetUnevaluatedPropertyValue("PlatformToolset")
If currentPlatformToolset = "v100" Then
generalRule.SetPropertyValue("PlatformToolset", "Windows7.1SDK")
End If
Next
End If
Next
End Sub
End Module
</pre>
You need to add references to the VCProject and VCProjectEngine assemblies in your macro project to access the types of the Visual C++ Project Model used in this macro.
Stay tuned for more useful functionality of IVCRulePropertyStorage.
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2011/11/26/modifying-a-visual-c-2010-projects-platform-toolset-programmatically-with-ivcrulepropertystorage/feed/</wfw:commentRss>
<slash:comments>3</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Visual Studio 2010 Beta 2 debugger may be confused by your symbol path</title>
<link>https://kobyk.wordpress.com/2009/11/05/visual-studio-2010-beta-2-debugger-may-be-confused-by-your-symbol-path/</link>
<comments>https://kobyk.wordpress.com/2009/11/05/visual-studio-2010-beta-2-debugger-may-be-confused-by-your-symbol-path/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Thu, 05 Nov 2009 18:30:37 +0000</pubDate>
<category><![CDATA[C++]]></category>
<category><![CDATA[Windbg]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=52</guid>
<description><![CDATA[I’ve been evaluating Microsoft’s Visual Studio 2010 Beta 2 release recently on my Windows 7 x64 system. As can be expected, the beta has quite a few rough edges, but overall I like the new WPF-based IDE GUI and the … <a href="https://kobyk.wordpress.com/2009/11/05/visual-studio-2010-beta-2-debugger-may-be-confused-by-your-symbol-path/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[I’ve been evaluating Microsoft’s Visual Studio 2010 Beta 2 release recently on my Windows 7 x64 system. As can be expected, the beta has quite a few rough edges, but overall I like the new WPF-based IDE GUI and the refreshed code Editor in particular (I like how selecting a block of code now preserves syntax highlighting while the block is highlighted, for instance).
The new GUI does have some badness. I had particular distaste for the poor aliasing of tooltips in the editor. This can be seen, for example, when hovering over a function name like “printf”. The menu bar’s dark blue color scheme also appears rather peculiar.
Besides the “bling”, notable changes include the Visual C++ 2010 CRT reverting to the traditional deployment model used by the Visual C++ 2003 CRT. More specifically, the CRT DLLs no longer use SxS binding (“Fusion”) and are now simply deployed to the “system32” directory or to the application’s directory, as desired. Dropping SxS has some obvious disadvantages (SxS binding redirects would no longer be able to redirect applications that load a private copy of the CRT DLLs to updated versions with bug fixes and security updates) but presumably the pain of integrating SxS deployment into the setup process, which required either an MSI installation or pseudo-documented use of the SxS API, resulted in too much negative feedback and they chose to revert to the legacy approach.
Visual C++ projects are now built with MSBuild, like their C# and other .NET counterparts. This should have several benefits. One that comes to mind is the the Windows Installer XML Toolset’s Votive (its VS IDE integration component) should be able to support C++ projects as References in addition to .NET projects.
A more important update to the project system is support for multi-targeting. Most of Microsoft’s discussions on the subject mainly deal with said support for .NET projects, with the new Visual Studio being able to target .NET 2.0 through .NET 4.0 on a per-project basis. However, similar support is offered for native multi-targeting. A per-project setting specifies the “toolset” with which it is to be built. The product comes built-in with toolset definitions for the VC++ 10 and the VC++ 9 compilers, but since toolset definitions are simple XML files describing tool paths, older compilers and custom definitions are easy to define. Indeed, a toolset definition can be found for the Windows 7 SDK build environment. I foresee using this functionality to build user-space applications with headers and tools from the Windows Driver Kit build environment, resulting in being able to link with the OS CRT (msvcrt.dll) in a clean way, without modifying global Visual C++ directory settings, but rather keeping the changes contained to specific projects.
My enthusiasm for testing the product was struck a severe blow when my first attempt to run the Visual C++ debugger on a “Hello, World!” console application went awry. The IDE was hung for a good 15-20 seconds. The IDE sat frozen for quite a bit after F10 was pressed to initiate the debugging session, finally presented the console window for the test application and then spent some more time being frozen. After a lengthy wait, the session was finally ready.
But the worst part was that when the debugging session was finally ready, debugging symbols for all modules except the application .exe and the VC 10 CRT were NOT loaded! It appeared as though the lengthy wait was all for naught.
The experience was sufficiently poor for me to report it to Microsoft through one of the feedback channels. I was eventually contacted by helpful folks from the Visual Studio Debugger team and we analyzed the problem in an e-mail exchange. The performance issue is the result of problematic contents of the symbol path I configured for the debugger.
As I mentioned, I’m evaluating the beta on a Windows 7 machine. For this reason, the Windows 7 symbol packages, available from Microsoft’s public symbols download page, are deployed in my system and are a part of the symbol path defined by the _NT_SYMBOL_PATH environment variable. Since this is an x64 machine and I find myself debugging 32-bit processes quite often, both the 32-bit and 64-bit symbol packages are installed. My initial symbol path was:
C:\Symbols;C:\Symbols32;CACHE*C:\websymbols;SRV*http://msdl.microsoft.com/download/symbols
The first issue with this symbol path is that the x64 symbols package (extracted to C:\Symbols) and the x86 symbols package (extracted to C:\Symbols32) are specified as directories in the symbol path, rather than symbol stores. This is what you’d expect from symbol packages designed for local deployment, but it turns out that the Windows 7 symbol packages, unlike the PDB packages for previous versions of Windows, come in the symbol store directory layout rather than the flat directory layout. This means, for example, that the symbols for ntdll.dll are in a path like C:\Symbols\ntdll.pdb\CFF40300FD804691B73E12CF2A150EE02\ntdll.pdb rather than the simpler C:\Symbols\dll\ntdll.pdb.
I did not notice this issue, however, before installing Visual Studio 2010 Beta 2, because apparently Windbg doesn’t mind when stores are specified in this syntax, as it exercises some sort of heuristic to determine the layout of a symbol directory. However, Visual Studio 2010 Beta 2 is not as liberal. Examining its I/Os with Sysinternals Process Monitor determined that it wasn’t trying to find PDBs under the symbol directories except directly under them or in a “dll” subdirectory, rather than looking for the appropriate hash as it would in a symbol store. The resolution for this issue is simple enough, refer to the Windows 7 symbol packages with SRV* syntax in the symbol path. Therefore, the symbol path is updated to something like:
SRV*C:\Symbols;SRV*C:\Symbols32;CACHE*C:\websymbols;SRV*http://msdl.microsoft.com/download/symbols
With this change in place, the Visual Studio 2010 Beta 2 debugger was able to pick up symbols for system DLLs from the local stores, and now the debugging session started instantly. But the question remained: even if the debugger didn’t know how to look for symbols under C:\Symbols and C:\Symbols32 when they were not specified with a srv* directive, why did it download symbols from the HTTP public store, only to end up starting with symbols not being loaded for any of the system DLLs in the debugged process?
To get to the bottom of this, the local symbol caches were removed from the symbol path. At this point, it was
CACHE*C:\websymbols;SRV*http://msdl.microsoft.com/download/symbols
Running the debugger with this stripped down symbol path reproduced the poor debugger startup experience and the worse issue of symbols being downloaded only to end up not being used. At this point, Sysinternals Process Monitor was used to examine the actions of the debugger. Two curious facts were revealed.
The first was that the Visual Studio debugger was literally examining a directory called “cache*C:\websymbols” under its path in a vain attempt to find symbols. Since the “cache*” string made it to a file open request, obviously the cache* directive in the _NT_SYMBOL_PATH variable was not being correctly parsed or understood by the debugger.
The result of this deficiency is that the Visual Studio debugger should be using some default local cache directory for the downloaded symbols, instead of the one explicitly specified by the cache* directive. Therefore, the same behavior would be expected with the following symbol path:
SRV*http://msdl.microsoft.com/download/symbols
And indeed, a quick check revealed that the same peculiarity reproduced with this symbol path setting: symbols were being downloaded from the HTTP server, but in the end of the process, symbols were not loaded for any of the system modules in the debugged process. Whatever the default directory is, attempts to download symbols there resulted in their loss into oblivion.
Specifying the local symbol cache using the SRV* directive is also possible. This is the legacy approach, before Windbg recommend using CACHE* instead. A symbol path of this form is
SRV*C:\websymbols*http://msdl.microsoft.com/download/symbols
With this symbol path in place, the Visual Studio 2010 Beta 2 debugger both downloaded symbols from the HTTP store and actually ended up using them. Specifying the cache directory with CACHE* or not at all triggered the bug, while specifying it the old fashioned way in the SRV* directive satisfied the debugger.
As a result, my guidance for the Visual Studio 2010 Beta 2 debugger users experiencing performance issues or other symbol problems that have no issue with their symbol path when used with Windbg is:
<ol>
<li>For each directory in your _NT_SYMBOL_PATH, determine whether it is in the “flat” format or in symbol store format. Prefix symbol stores with SRV*, changing “C:\Symbols” to “SRV*C:\Symbols”. Windows 7 users in particular should be aware that the symbol packages for their platforms should be specified with SRV* syntax for Visual Studio 2010 Beta 2.</li>
<li>Specify local caches directories for remote symbol stores (SMB or HTTP) directly in the SRV* directive, to have Visual Studio 2010 Beta 2 pick them up. It is OK to keep the CACHE* directive in your symbol path as well, but for the time being, Visual Studio 2010 Beta 2 does not seem to use it correctly.</li>
</ol>
The Visual Studio Debugger team is addressing issues revealed by the investigation of this behavior for the forthcoming RTM release of Visual Studio 2010. However, several significant deficiencies in debugger symbol support will not be addressed in the 2010 release. One is that symbol loading is done synchronously rather than asynchronously to the debugging session. The other being that unless manual symbol loading is used, no progress indication nor cancellation UI is presented as the symbols are being transferred from a remote store. Therefore, the perceived performance of symbol support in the debugger will leave something to be desired for the time being.
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2009/11/05/visual-studio-2010-beta-2-debugger-may-be-confused-by-your-symbol-path/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>IDA v5.4 supports Windbg as a debugger backend</title>
<link>https://kobyk.wordpress.com/2009/01/30/ida-v54-supports-windbg-as-a-debugger-backend/</link>
<comments>https://kobyk.wordpress.com/2009/01/30/ida-v54-supports-windbg-as-a-debugger-backend/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Fri, 30 Jan 2009 19:16:32 +0000</pubDate>
<category><![CDATA[Kernel]]></category>
<category><![CDATA[Windbg]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=48</guid>
<description><![CDATA[A new release of IDA, the Interactive Disassembler, has been recently released featuring new debugger integration capabilities. IDA’s existing built-in debugger often proved lackluster, but IDA’s static analysis and navigation features are, of course, unrivaled by anything else. I always … <a href="https://kobyk.wordpress.com/2009/01/30/ida-v54-supports-windbg-as-a-debugger-backend/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[A new release of IDA, the Interactive Disassembler, has been recently released featuring new debugger integration capabilities. IDA’s existing built-in debugger often proved lackluster, but IDA’s static analysis and navigation features are, of course, unrivaled by anything else. I always wished IDA would address the weakness of its debugging features and now they have done so in the v5.4 release. The new version can drive a gdb debugging server (as embedded platforms often provide), a Bochs virtual machine (great for BIOS and boot loader debugging) and most importantly DbgEng, the Microsoft debugging engine used by Windbg. Since Windbg sessions often involve heavy use of PDBs, IDA v5.4 has improved its support for importing data from PDBs and now uses more of their embedded type information (previously the third party Determina PDB plugin attempted to improve IDA’s PDB support). To top things off, the Python plugin is now bundled with IDA, as well.
I haven’t had the chance to use the new version yet, but Hex Rays have a great demo video <a href="http://hexblog.com/2009/01/kernel_debugging_with_ida.html">posted here</a>. The only thing notable that appears missing is a nice UI for examining the stack trace, but if push comes to shove the Windbg command line can be used to invoke “k”, as demonstrated.
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2009/01/30/ida-v54-supports-windbg-as-a-debugger-backend/feed/</wfw:commentRss>
<slash:comments>4</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Windbg 6.10.3.233 released</title>
<link>https://kobyk.wordpress.com/2008/11/21/windbg-6103233-released/</link>
<comments>https://kobyk.wordpress.com/2008/11/21/windbg-6103233-released/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Fri, 21 Nov 2008 05:50:02 +0000</pubDate>
<category><![CDATA[Windbg]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=43</guid>
<description><![CDATA[Version 6.10.3.233 of the Debugging Tools for Windows package has been available for a few days now. The big news on this one is lots of FireWire debugging changes. An updated host driver is provided and claims of greater reliability … <a href="https://kobyk.wordpress.com/2008/11/21/windbg-6103233-released/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[Version 6.10.3.233 of the Debugging Tools for Windows package has been available for a few days now.
The big news on this one is lots of FireWire debugging changes. An updated host driver is provided and claims of greater reliability and controller compatibility are made. Additional changes include better WOW64 support, claims of performance improvements to the various debuggers in the package (it remains to be seen how significant those are), many improvements to the almighty !analyze extension command and extensive updates to the debugger documentation. Absent from this release is NT 4.0 support. I suppose not many will miss it at this point.
Developers using the debugger API may be interested that symbols for dbghelp.dll v6.10.3.233 are available from the public symbol store, while symbols for dbgeng.dll v6.10.3.233 are once again missing, a sorry tradition of making the debugger interface consumer’s life hard since the 6.8 debugger release, if I recall correctly.
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/11/21/windbg-6103233-released/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Oops! Microsoft private symbols accidently leaked in Visual Studio 2010 CTP VM image</title>
<link>https://kobyk.wordpress.com/2008/10/29/oops-microsoft-private-symbols-accidently-leaked-in-visual-studio-2010-ctp-vm-image/</link>
<comments>https://kobyk.wordpress.com/2008/10/29/oops-microsoft-private-symbols-accidently-leaked-in-visual-studio-2010-ctp-vm-image/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Wed, 29 Oct 2008 15:08:18 +0000</pubDate>
<category><![CDATA[Windbg]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=41</guid>
<description><![CDATA[I downloaded Microsoft’s newly released Visual Studio 2010 CTP virtual machine disk image hoping for a few surprises, but I certainly didn’t expect this… The Visual Studio 2010 CTP is a huge multi-gigabyte VM running Windows Server 2008. The first … <a href="https://kobyk.wordpress.com/2008/10/29/oops-microsoft-private-symbols-accidently-leaked-in-visual-studio-2010-ctp-vm-image/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[I downloaded Microsoft’s newly released Visual Studio 2010 CTP virtual machine disk image hoping for a few surprises, but I certainly didn’t expect this…
The Visual Studio 2010 CTP is a huge multi-gigabyte VM running Windows Server 2008. The first thing I did with it is start up Visual C++ 2010, create a Win32 console application and run it in the debugger. I looked at the stack trace and saw the following: 
<code> 
vc10app.exe!wmain(int argc=1, wchar_t * * argv=0x000d1470) Line 8 
vc10app.exe!__tmainCRTStartup() Line 564 + 0x19 bytes 
vc10app.exe!wmainCRTStartup() Line 392 
kernel32.dll!BaseThreadInitThunk(unsigned long RunProcessInit=0, long (void *)* StartAddress=0x00000000, void * Argument=0x7ffdf000) Line 66 + 0x5 bytes 
ntdll.dll!__RtlUserThreadStart(long (void *)* StartAddress=0x013b1073, void * Argument=0x7ffdf000) Line 2740 
ntdll.dll!_RtlUserThreadStart(long (void *)* StartAddress=0x013b1073, void * Argument=0x7ffdf000) Line 2672 + 0xb bytes</code>
vc10app is the name of my test console application. I go over stack traces on a daily basis so the special thing about this one immediately caught my attention. Notice that the wmain() function of my console application has full debugging information (as expected for something I wrote) and the parameter names argc and argv are visible in the stack trace. Under normal circumstances, only public debugging symbols are available for Microsoft OS components like kernel32 and ntdll. In this CTP VM, however, the StartAddress and Argument parameters were visible as well.
Public debugging symbols are stripped versions of the original private symbols generated by the build process. They do not contain parameter information and do not contain the names of local variables in functions. Note however that for C++ functions, name mangling results in parameter types being visible in public symbols as well. Normally, when running the debugger in a system configured to use Microsoft’s public symbols, names for internal functions are visible in stack traces, but the names of arguments and locals never are.
I opened the Modules tab of the Visual Studio debugger to determine where the debugger is picking up these symbols for kernel32 and ntdll. The debugger was using C:\ppa\symstore as the symbol store. I opened the C:\ppa directory and saw that a Visual Studio Profiler session for a matrix multiplication application was stored there.
Apparently someone with access to Microsoft’s internal symbol store ran a profiling session on this matrix multiplication application, perhaps to ensure profiling is functional on the CTP VM. The private symbols retrieved for the session were persisted in the CTP’s disk and made their way to the public release. To ensure my hypothesis was correct, I installed Windbg on the machine, opened ntdll.dll as a crash dump and loaded symbols from the store directory: 
<code> 
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86 
Copyright (c) Microsoft Corporation. All rights reserved. 
Loading Dump File [C:\Windows\System32\ntdll.dll] 
Symbol search path is: SRV*c:\ppa\symcache;. 
Executable search path is: 
ModLoad: 77ed0000 77ff7000 C:\Windows\System32\ntdll.dll 
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000 
eip=77ed0000 esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na po nc 
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000 efl=00000000 
ntdll!`string'
(ntdll+0x0): 
77ed0000 4d dec ebp 
0:000> .reload /f 
. 
Loading unloaded module list 
0:000> lm 
start end module name 
77ed0000 77ff7000 ntdll (private pdb symbols) c:\ppa\symcache\ntdll.pdb\B958B2F91A5A46B889DAFAB4D140CF252\ntdll.pdb 
0:000> x ntdll!RtlAllocateHeap 
77f358a6 ntdll!RtlAllocateHeap (void *, unsigned long, unsigned long) 
0:000> dv /f ntdll!RtlAllocateHeap 
@ebp+0x08 HeapHandle 
@ebp+0x0c Flags 
@ebp+0x10 Size 
@ebp+0x08 ExtraSize 
@ebp-0x04 AllocationSize 
@ebp-0x08 Interceptor 
@ebp-0x58 ExceptionRecord</code>
The private PDB for ntdll.dll found in this CTP VM image notes how HeapHandle, Flags, Size and ExtraSize are the parameter names for RtlAllocateHeap. Furthermore, AllocationSize, Interceptor and ExceptionRecord are used as local names in this API.
Private PDBs also feature source information. This is also visible in this case: 
<code> 
0:000> ln ntdll!RtlAllocateHeap 
d:\rtm\base\ntos\rtl\heap.c(1508) 
Source Depot: basedepot.sys-ntgroup.ntdev.microsoft.com:2003 //depot/longhorn_rtm/base/ntos/rtl/heap.c#1 
(77f358a6) ntdll!RtlAllocateHeap | (77f35997) ntdll!RtlpLowFragHeapFree 
Exact matches: 
ntdll!RtlAllocateHeap (void *, unsigned long, unsigned long)</code>
The PDB features references to the source file from the Windows source tree for RtlAllocateHeap and the other APIs. Additionally, it appears to contain a custom reference to Microsoft’s internal source control system, Source Depot, presumably to facilitate the debugger retrieving up to date sources automatically when those are not available locally.
It’s interesting how scattered bits of information in a debugging symbols file provide a fascinating insight into Windows. Hope you enjoyed the surprise as much as I did…
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/10/29/oops-microsoft-private-symbols-accidently-leaked-in-visual-studio-2010-ctp-vm-image/feed/</wfw:commentRss>
<slash:comments>9</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Installing filter drivers with DIFxApp and a WiX v3 MSI</title>
<link>https://kobyk.wordpress.com/2008/10/21/installing-filter-drivers-with-difxapp-and-a-wix-v3-msi/</link>
<comments>https://kobyk.wordpress.com/2008/10/21/installing-filter-drivers-with-difxapp-and-a-wix-v3-msi/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Mon, 20 Oct 2008 21:11:01 +0000</pubDate>
<category><![CDATA[Kernel]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=36</guid>
<description><![CDATA[The designers of Windows Installer probably did not have driver installation in mind. Indeed, the ServiceInstall MSI database table does not even allow for service types SERVICE_KERNEL_DRIVER and SERVICE_FILE_SYSTEM_DRIVER in the ServiceType column. Originally, Microsoft encouraged driver installation by means … <a href="https://kobyk.wordpress.com/2008/10/21/installing-filter-drivers-with-difxapp-and-a-wix-v3-msi/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[The designers of Windows Installer probably did not have driver installation in mind. Indeed, the <a href="http://msdn.microsoft.com/en-us/library/aa371637(VS.85).aspx">ServiceInstall MSI database table</a> does not even allow for service types SERVICE_KERNEL_DRIVER and SERVICE_FILE_SYSTEM_DRIVER in the ServiceType column. Originally, Microsoft encouraged driver installation by means of a “setup application”, custom code invoking the <a href="http://msdn.microsoft.com/en-us/library/cc185682(VS.85).aspx">SetupAPI</a>. The Setup API functions would be used to examine an <a href="http://msdn.microsoft.com/en-us/library/ms790220.aspx">.INF file</a> describing required steps for the driver’s installation. Back in Windows NT 4.0, even .INF files were often avoided in lieu of directly setting up the legacy driver service in the system registry with C code.
Enter Windows 2000 with Plug and Play. Now the system uses .INF files it maintains in a store to locate and install drivers for devices on demand. When a new device is inserted, the system looks for an .INF file with a matching hardware identifier. For most hardware devices, .INF based installation becomes a de-facto requirement. However, for other driver categories, such as file system filters, device class filters, etc., an .INF file is but one way of performing the driver installation process.
Microsoft, when confronted by driver setup authors who denounce .INF files as having cryptic, old-fashioned syntax, non-ideal diagnosibility and debuggability and other shortcomings, persists in encouraging their use. They are a WHQL logo requirement and in some cases it is claimed they will be the only way to install drivers in future Windows releases.
Often driver installation is but a part of the installation process of a larger application program. For applications, Microsoft encourages (and mandates as a logo requirement) the use of MSI packages and the Windows Installer service. In order to avoid having every MSI setup author who needs to perform driver installation roll his own custom invocation of the driver’s .INF installation and in a bid to improve driver installation’s synergy with Windows Installer in general, Microsoft created <a href="http://msdn.microsoft.com/en-us/library/ms790295.aspx">DIFxApp</a> – Driver Install Frameworks for Applications.
MSI and DIFxApp’s .INF based installation make for an odd couple. The Windows Installer model is transactional – describe what changes should be made to the system and let Windows Installer determine how to execute them and importantly, how to roll them back. After having encouraged COM DLLs to encapsulate the details of their installation and registration with the Self-Registration DllRegisterServer export for years, describing the individual elements of the COM registration using an MSI’s <a href="http://msdn.microsoft.com/en-us/library/aa371168(VS.85).aspx">Registry table</a> is now encouraged instead. DllUnregisterServer can fail in mysterious ways due to missing dependencies, etc., leaving cruft behind during uninstallation. By contrast, rolling back insertions made from the Registry table is always possible for the MSI service. If COM’s long standing installation architecture was set aside to better align with MSI’s model, one would expect a similar occurance for drivers. However, DIFxApp, the solution for installing drivers with MSI, is the moral equivalent of COM Self-Registration. If a driver’s .INF does not remove all changes it made during installation, the uninstallation process is bound to be imperfect. MSI’s ability to diagnose whether a driver’s installation has been damaged is limited and thwarted.
Be that as it may, .INF files’ tight integration with the Plug and Play system, the fact they are a logo requirement and uniformity considerations are compelling arguments for their use. From this point forward, it shall be assumed that .INF based installation and MSI integration have been chosen.
If you’ve developed a common PnP WDM driver, you probably already have an .INF for installation purposes. That .INF can usually be used as is with DIFxApp, which assumes PnP drivers by default. It is for other driver categories that the process becomes more tricky. I’ll discuss filter drivers of three varieties in particular – file system filters, file system minifilters and device class filters.
For illustration purposes, let’s consider a typical file system minifilter driver, DirFilter, which is presently a pet project of mine that will eventually perform interesting modifications to directory listing I/O operations. The following is DirFilter’s .INF file:
<code> 
[Version] 
Signature = "$Windows NT$" 
Class = "ActivityMonitor" 
ClassGuid = {b86dff51-a31e-4bac-b3cf-e8cfe75c9fc2} 
Provider = %Koby% 
DriverVer = 09/12/2008,1.0.0.0 
CatalogFile = dirfilter.cat 
DriverPackageType = FileSystemMinifilter 
[DestinationDirs] 
DefaultDestDir = %DIRID_DRIVERS% 
DirFilter.DriverFiles = %DIRID_DRIVERS% 
[DefaultInstall] 
OptionDesc = %ServiceDescription% 
CopyFiles = DirFilter.DriverFiles 
[DefaultInstall.Services] 
AddService = %ServiceName%,,DirFilter.Service 
[DefaultUninstall] 
DelFiles = DirFilter.DriverFiles 
[DefaultUninstall.Services] 
DelService = %ServiceName%,0x200 ;Ensure service is stopped before deleting 
[DirFilter.Service] 
DisplayName = %ServiceName% 
Description = %ServiceDescription% 
ServiceBinary = %12%\%DriverName%.sys ; DIRID_DRIVERS 
Dependencies = "FltMgr" 
ServiceType = %SERVICE_FILE_SYSTEM_DRIVER% 
StartType = %SERVICE_DEMAND_START% 
ErrorControl = %SERVICE_ERROR_NORMAL% 
LoadOrderGroup = "FSFilter Activity Monitor" 
AddReg = DirFilter.AddRegistry 
[DirFilter.AddRegistry] 
HKR,"Instances","DefaultInstance",0x00000000,%Instance1.Name% 
HKR,"Instances\"%Instance1.Name%,"Altitude",0x00000000,%Instance1.Altitude% 
HKR,"Instances\"%Instance1.Name%,"Flags",0x00010001,%Instance1.Flags% 
[DirFilter.DriverFiles] 
%DriverName%.sys 
[SourceDisksFiles] 
dirfilter.sys = 1 
[SourceDisksNames] 
1 = %DiskId1% 
[Strings] 
Koby = "Koby Kahane" 
DIRID_DRIVERS = 12 
SERVICE_FILE_SYSTEM_DRIVER = 2 
SERVICE_DEMAND_START = 2 
SERVICE_ERROR_NORMAL = 1 
ServiceDescription = "DirFilter minifilter driver" 
ServiceName = "DirFilter" 
DriverName = "DirFilter" 
DiskId1 = "DirFilter minifilter installation media" 
; Instance specific information. 
Instance1.Name = "DirFilter Instance" 
Instance1.Altitude = "370021" ; Real world minifilters should use Microsoft allocated altitude 
Instance1.Flags = 0x0 ; Allow automatic attachments</code>
This is, I believe, a pretty typical .INF for a minifilter. A default instance of it is set up at an altitude in an appropriate filter load order group. This is as good a place as any to note the importance of requesting a <a href="http://connect.microsoft.com/content/content.aspx?ContentID=2512&SiteID=221">Minifilter Altitude Allocation</a> from Microsoft for public drivers rather than using some random number which may end up causing conflicts and interoperability issues. From my experience, it takes Microsoft two months or so to respond to an allocation request so make sure to take care of it early in your release cycle.
As a first step towards a DIFxApp-based MSI driver installation, write an .INF file that will work when right clicking it and selecting Install from Explorer’s popup menu. This calls SetupAPI’s <a href="http://msdn.microsoft.com/en-us/library/aa376957(VS.85).aspx">InstallHinfSection</a> on the .INF file’s <a href="http://msdn.microsoft.com/en-us/library/aa376957(VS.85).aspx">DefaultInstall</a> section. Further, ensure that the uninstallation process works as expected, and leaves no trails behind, by using InstallHinfSection to invoke the DefaultUninstall section of the file.
You may discover that you are encountering difficulty at this stage. I recommend running the <a href="http://msdn.microsoft.com/en-us/library/ms792443.aspx">ChkINF</a> utility, which analyzes .INF files for errors and mishaps, before testing the .INF file and indeed after every modification to an existing file. ChkINF, while sometimes terse, is nowhere near as cryptic as errors you will receive from SetupAPI. However, if you encounter setup errors even after ChkINF has verified your file, you can utilize <a href="http://msdn.microsoft.com/en-us/library/ms791354.aspx">verbose SetupAPI logging</a> to further diagnose setup issues.
With a working “right-click Install” .INF file, the time is ripe for integration into an MSI installer. First of all, DIFxApp requires an additional directive in the <a href="http://msdn.microsoft.com/en-us/library/ms794526.aspx">Version section</a> of your .INF file, the <a href="http://msdn.microsoft.com/en-us/library/ms790242.aspx">DriverPackageType</a>. The driver package type is used by DIFx to determine what steps are required for the installation of your specific type of driver. For example, if you fail to specify the type of your file system filter, DIFx assumes it is a PnP driver and the “installation” will just import the .INF into the system driver store. No service will be created and success will not be achieved. Unfortunately, the documentation for the DriverPackageType is sorely lacking at best. You will see it only mentions ClassFilter and PlugAndPlay as possible types in MSDN. MSDN proves a disappointment. However, another Microsoft information source, their <a href="http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/DIFXtools_reqs.doc">Requirements for Driver Packages that are Used with the DIFx Tools</a> document, calls for the use of DIFx for Class Filters, Plug and Play drivers, File System & File System Filter drivers, Network drivers, Kernel Service Drivers and Export Drivers. The DriverPackageType values ClassFilter, FileSystem, FileSystemFilter, KernelModule, KernelService, Network and PlugAndPlay are documented there. You may notice that a special type for minifilters is conspicuously absent from the list. At first, I figured perhaps DIFx has no need for a distinction between legacy filters and minifilters. Later, an <a href="http://www.osronline.com/showThread.cfm?link=62820">old post</a> (free registration required) on OSR’s NTFSD mailing list turned my attention to the fact DIFx will require a system restart for a minifilter, even though it can be loaded and unloaded without one. Neal Christiansen, Microsoft’s File System Filter Group Lead, replies (back in 2004) that appropriate support for minifilter installation is forthcoming. I therefore set out to discover whether DIFxApp as available today provides special support for minifilters.
When the Windows Server 2008 WDK is installed to the default location, the x86 versions of the DIFxApp MSI custom action DLLs reside in C:\WINDDK\6001.18000\redist\DIFx\DIFxApp\English\WixLib\x86. I examined them with the <a href="http://www.hex-rays.com/idapro/">Interactive Disassembler</a> and was happy to see Microsoft made available public symbols (.PDBs) for them. To make a long story short, the DriverPackageType field is examined by DIFxApp in the SetupAPI::CDriverPackage::GetDriverType(CRefPtr<SetupAPI::CInf>, DRVPKG_TYPE&) function in DIFxAppA.dll, which references a global table, dubbed DriverTypeStringList, for possible package types:
<a href="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist.png"><img data-attachment-id="39" data-permalink="https://kobyk.wordpress.com/2008/10/21/installing-filter-drivers-with-difxapp-and-a-wix-v3-msi/drivertypestringlist1/" data-orig-file="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png" data-orig-size="1247,263" data-comments-opened="1" data-image-meta="{"aperture":"0","credit":"","camera":"","caption":"","created_timestamp":"0","copyright":"","focal_length":"0","iso":"0","shutter_speed":"0","title":""}" data-image-title="DriverTypeStringList" data-image-description="" data-image-caption="" data-medium-file="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=300" data-large-file="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=584" class="alignnone size-full wp-image-39" title="DriverTypeStringList" src="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=584" alt="" srcset="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=446&h=94 446w, https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=891&h=188 891w, https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=150&h=32 150w, https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=300&h=63 300w, https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png?w=768&h=162 768w" sizes="(max-width: 450px) 100vw, 450px" /></a>
It is now evident that available driver package types as of DIFx 2.1 are ClassCoInstaller, ClassFilter, DeviceFilter, FileSystem, FileSystemFilter, FileSystemMinifilter, KernelModule, KernelService, NdisImMiniport, Network and PlugAndPlay. With this information, I opted for the FileSystemMinifilter type for DirFilter’s installation .INF file.
Next, a catalog file is required by DIFx. Even though the purpose of the catalog is to be WHQL signed by Microsoft, DIFx can be used to install drivers without WHQL certification. Nevertheless, the catalog still needs to be there. The easy way is to use the <a href="http://msdn.microsoft.com/en-us/library/bb931742.aspx">Inf2Cat</a> tool for the catalog’s generation. Place the .INF file and the driver files it references in a staging area and you can run it like so: 
<code> 
E:\Projects\dirfilter\staging>inf2cat /driver:E:\Projects\dirfilter\staging /os:Server2008_X86,Vista_X86,Server2003_X86,XP_X86,2000 /verbose</code>
Specifying, of course, the operating systems and platforms appropriate for your driver.
An .INF file, a .CAT file and a .SYS file are the three files required for a DIFxApp driver package. The DIFxApp model requires your MSI to install these files to a source directory, per driver package (i.e., if you have multiple drivers, they’ll need multiple .INFs in multiple directories) and performs the installation from there to the Windows driver store and eventually the drivers directory under system32.
Microsoft distributes a WiX library and documentation for using it with DIFxApp. However, that library targets the older WiX v2.0 release. WiX v3.0 is the actively developed version, and has different schema, semantics and a slightly different integration model with DIFxApp. If you use WiX v2.0, consult <a href="http://msdn.microsoft.com/en-us/library/ms790289.aspx">Microsoft’s documentation</a>. Otherwise, let’s proceed. The following .wxs file is the sample installer I wrote for installing DirFilter with DIFxApp:
<pre class="brush: xml; title: ; notranslate">
<?xml version='1.0' encoding='windows-1252'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
xmlns:difx='http://schemas.microsoft.com/wix/DifxAppExtension'>
<Product Name='DirFilterInstaller' Id='59486bf1-77ad-460f-802d-29dbab0f78be' Language='1033' Codepage='1252' Version='1.0' Manufacturer='KK' UpgradeCode='96fe2ba0-fe8b-45b4-85ef-ea9aca103e6f'>
<Package Id='*' Keywords='DirFilter' Description='DirFilter Installer' Comments='Installs DirFilter' Manufacturer='KK' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' />
<Media Id='1' Cabinet='DirFilterInstaller.cab' EmbedCab='yes' DiskPrompt='DirFilter Media' />
<Property Id='DiskPrompt' Value='DirFilter Install Media' />
<Directory Id='TARGETDIR' Name='SourceDir'>
<Directory Id='ProgramFilesFolder'>
<Directory Id='INSTALLDIR' Name='DirFilterApp'>
<Directory Id='DirFilterAppDrivers' Name='Drivers'>
<Directory Id='DirFilterDir' Name='DirFilter'>
<Component Id='DirFilterDriver' Guid='8c64e674-5476-46e4-93cd-ba1ae78622df'>
<File Id='DirFilterSYS' Name='DirFilter.sys' DiskId='1' Source='DirFilter.sys' KeyPath='yes' />
<File Id='DirFilterINF' Name='DirFilter.inf' DiskId='1' Source='DirFilter.inf' />
<File Id='DirFilterCAT' Name='DirFilter.cat' DiskId='1' Source='DirFilter.cat' />
<difx:Driver Legacy='yes' />
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id='Complete' Level='1'>
<ComponentRef Id='DirFilterDriver' />
</Feature>
<UIRef Id="WixUI_Minimal" />
</Product>
</Wix>
</pre>
Several points are worth mentioning regarding this installer:
<ul>
<li>The XML schema for the WiX v3 DIFxApp extension is referenced at the top of the file. This is required for the Driver element to work. Note that in WiX v3, the Driver element is used instead of driver-specific attributes that were available for the Component element in the WiX v2 DIFxApp extension.</li>
<li>As said before, DIFx requires one driver per directory and one driver per .INF file. The driver component is placed in a directory under the application’s directory. Additional drivers will be placed in additional components under additional directories.</li>
<li>The “Legacy” attribute is used in the DIFx Driver element because my driver package is not WHQL signed. Of course the best solution for this is to ensure your driver is up to par and actually get WHQL certification. You should also note that Legacy mode disables integrity checks, allowing the driver installation to appear successful even when critical files are missing, etc.</li>
<li>Do NOT copy the GUIDs I used if you end copying and pasting from this example. Make sure you generate your own with <a href="http://msdn.microsoft.com/en-us/library/aa373930(VS.85).aspx">uuidgen</a> and replace them.</li>
</ul>
The .wxs source for this WiX installer is straightforward enough. However, actually compiling it and linking it requires referencing several external dependencies. When running Candle, the WiX compiler, the WixDifxAppExtension should be referenced (and others you may depend on, such as WixUIExtension). When running Light, the WiX linker, you should reference the extension as before. Additionally, in the newer builds of WiX v3.0, multiplatform support for DIFx requires you reference the .wixlib with the DIFxApp custom action DLLs for the appropriate platform:
<code> 
E:\Projects\dirfilter\staging>%WIX_PATH%\candle -ext %WIX_PATH%\WixUIExtension.dll -ext %WIX_PATH%\WixDifxAppExtension.dll DirFilterInstaller.wxs 
Microsoft (R) Windows Installer Xml Compiler version 3.0.4617.0 
Copyright (C) Microsoft Corporation. All rights reserved. 
</code><code> 
DirFilterInstaller.wxs 
</code><code> 
E:\Projects\dirfilter\staging>%WIX_PATH%\light -ext %WIX_PATH%\WixUIExtension.dll - 
ext %WIX_PATH%\WixDifxAppExtension.dll DirFilterInstaller.wixobj %WIX_PATH%\difx 
app_x86.wixlib -o DirFilterInstaller.msi 
Microsoft (R) Windows Installer Xml Linker version 3.0.4617.0 
Copyright (C) Microsoft Corporation. All rights reserved.</code>
(The WIX_PATH environment variable is set to WiX 3.0’s bin directory on my system.)
Failing to reference WixDifxAppExtension or difxapp_[platform].wixlib will result in assorted compilation or linkage errors during installer build.
When debugging DIFxApp driver installation, usually the interesting things are performed by the SetupAPI directly and therefore the SetupAPI log should be examined first. However, DIFxApp’s custom actions write diagnostic information into the MSI log (which can be enabled with a command-line switch to msiexec) and can provide additional insight into the driver installation process. Here’s an excerpt from the MSI log of a successful DirFilter installation: 
<code> 
MSI (s) (2C:44) [20:22:39:061]: Executing op: ActionStart(Name=MsiInstallDrivers,,) 
Action 20:22:39: MsiInstallDrivers. 
MSI (s) (2C:44) [20:22:39:077]: Executing op: CustomActionSchedule(Action=MsiInstallDrivers,ActionType=3073,Source=BinaryData,Target=InstallDriverPackages,CustomActionData=2.15{8C64E674-5476-46E4-93CD-BA1AE78622DF}C:\Program Files\DirFilterApp\Drivers\DirFilter\82DirFilterInstallerKK) 
MSI (s) (2C:90) [20:22:39:092]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI29.tmp, Entrypoint: InstallDriverPackages 
DIFXAPP: ENTER: InstallDriverPackages() 
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'. 
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'. 
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{8C64E674-5476-46E4-93CD-BA1AE78622DF}'. 
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is 'C:\Program Files\DirFilterApp\Drivers\DirFilter\'. 
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0x8. 
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'. 
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is 'DirFilterInstaller'. 
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is 'KK'. 
DIFXAPP: INFO: user SID of user performing the install is 'S-1-5-21-1417001333-651377827-725345543-1003'. 
DIFXAPP: INFO: opening HKEY_USERS\S-1-5-21-1417001333-651377827-725345543-1003\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Components\{8C64E674-5476-46E4-93CD-BA1AE78622DF} (User's SID: 'S-1-5-21-1417001333-651377827-725345543-1003') ... 
DIFXAPP: INFO: ENTER: DriverPackageInstallW 
DIFXAPP: INFO: Copied 'DirFilter.inf' to driver store... 
DIFXAPP: INFO: Copied 'dirfilter.cat' to driver store... 
DIFXAPP: INFO: Commiting queue... 
DIFXAPP: INFO: Copied file: 'C:\Program Files\DirFilterApp\Drivers\DirFilter\dirfilter.sys' -> 'C:\WINDOWS\system32\DRVSTORE\DirFilter_11E71DD96C3AADF7CDEC882620E8410DECE9B5EF\dirfilter.sys'. 
DIFXAPP: INFO: Installing INF file "C:\WINDOWS\system32\DRVSTORE\DirFilter_11E71DD96C3AADF7CDEC882620E8410DECE9B5EF\DirFilter.inf" of Type 4. 
DIFXAPP: INFO: Installing File System Driver 'C:\WINDOWS\system32\DRVSTORE\DirFilter_11E71DD96C3AADF7CDEC882620E8410DECE9B5EF\DirFilter.inf' 
DIFXAPP: INFO: Service 'DirFilter' was started 
DIFXAPP: SUCCESS:Installation completed with code 0x0. 
DIFXAPP: INFO: RETURN: DriverPackageInstallW (0x0) 
DIFXAPP: INFO: ENTER: DriverPackageGetPathW 
DIFXAPP: SUCCESS:Found driver store entry. 
DIFXAPP: INFO: RETURN: DriverPackageGetPathW (0x7A) 
DIFXAPP: INFO: ENTER: DriverPackageGetPathW 
DIFXAPP: SUCCESS:Found driver store entry. 
DIFXAPP: INFO: RETURN: DriverPackageGetPathW (0x0) 
DIFXAPP: INFO: driver store entry for 'C:\Program Files\DirFilterApp\Drivers\DirFilter\DirFilter.inf' is 'C:\WINDOWS\system32\DRVSTORE\DirFilter_11E71DD96C3AADF7CDEC882620E8410DECE9B5EF\DirFilter.inf'. 
DIFXAPP: INFO: The component Id '{8C64E674-5476-46E4-93CD-BA1AE78622DF}' is now set to point to driver store: 'C:\WINDOWS\system32\DRVSTORE\DirFilter_11E71DD96C3AADF7CDEC882620E8410DECE9B5EF\DirFilter.inf' 
DIFXAPP: INFO: A reboot is not needed to install the component '{8C64E674-5476-46E4-93CD-BA1AE78622DF}'. 
DIFXAPP: RETURN: InstallDriverPackages() 0 (0x0)</code>
Notice how DIFxApp places a copy of your driver package in the system driver store, a behavior which is distinct from “right-click Install” .INF invocation. Notice also it reports whether the installation operation with SetupAPI was successful and will additionally take care of scheduling a reboot if the driver package so requires.
DIFxApp works equally well for installing a legacy file system filter. Simply use the FileSystemFilter DriverPackageType value instead.
Device class filters require special consideration. MSDN has a page about <a href="http://msdn.microsoft.com/en-us/library/ms791322.aspx">Installing a Filter Driver</a>. For device filters, the process is straightforward – your .INF simply adds an UpperFilter under the appropriate device’s hardware key, using the special “HKR” relative root. However, a device class filter has no hardware key to refer to and indeed may wish to filter several distinct device classes. The MSDN page says one ought to write a custom “setup application” that shall invoke the .INF file for the several device classes of interest, as desired. However, DIFxApp offers no such flexibility and it does not appear that it can be used to drive such an .INF file. However, the fact it has a ClassFilter type clearly implies it has device class filters in mind.
As is often the case, the answer to this dillemma lies in the WDK. The WDK features a sample WiX v2.0 project for illustrating DIFxApp’s use, which in fact installs a class filter. In a default installation, you can find it in C:\WINDDK\6001.18000\src\setup\DIFxApp\WiXLib\ClassFilter.wxs. Nearby, in C:\WINDDK\6001.18000\src\setup\infs\clasfilt\ClasFilt.Inf, resides the sample .INF file. Among other things, the file includes an explicit registration as a class UpperFilter: 
<code> 
[ClassFilter_AddReg] 
; 
; Change {setup-ClassGUID} to the string form of the ClassGUID that you are installing the filter on. 
; 
; Change UpperFilters to LowerFilters if this is a lower class filter. 
; 
HKLM, System\CurrentControlSet\Control\Class\{setup-ClassGUID}, UpperFilters, 0x00010008, clasfilt</code>
Fair enough. Multiple entries can be included in the registry section for UpperFilter registration directly under the class keys of interest. However, if you opt for this approach you may find to your dismay you no longer fall in ChkINF’s favor: 
<code> 
(W22.1.2213) INF files should not set registry entries under 'HKLM,System\CurrentControlSet\Control\Class'.</code>
I guess you’re damned if you do and damned if you don’t. I suggest not drinking ChkINF’s Kool-Aid, setting up the device class filter registration directly and using DIFxApp rather than iterating with a custom setup application, obviously.
Hopefully this lengthy writeup will prove useful to other authors of MSI-based driver installations.
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/10/21/installing-filter-drivers-with-difxapp-and-a-wix-v3-msi/feed/</wfw:commentRss>
<slash:comments>15</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
<media:content url="https://kobyk.files.wordpress.com/2008/10/drivertypestringlist1.png" medium="image">
<media:title type="html">DriverTypeStringList</media:title>
</media:content>
</item>
<item>
<title>Implementing an LSA proxy authentication package</title>
<link>https://kobyk.wordpress.com/2008/08/30/implementing-an-lsa-proxy-authentication-package/</link>
<comments>https://kobyk.wordpress.com/2008/08/30/implementing-an-lsa-proxy-authentication-package/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Sat, 30 Aug 2008 14:57:26 +0000</pubDate>
<category><![CDATA[C++]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=33</guid>
<description><![CDATA[LSA authentication packages are a part of the core security ecosystem in Windows NT. LSA APs are provided with credentials by logon applications, such as Winlogon, authenticate these credentials and provide the logon application with a logon session handle if … <a href="https://kobyk.wordpress.com/2008/08/30/implementing-an-lsa-proxy-authentication-package/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[<a href="http://msdn.microsoft.com/en-us/library/aa374733(VS.85).aspx">LSA authentication packages</a> are a part of the core security ecosystem in Windows NT. LSA APs are provided with credentials by logon applications, such as Winlogon, authenticate these credentials and provide the logon application with a logon session handle if authentication was successful. Two authentication packages provided with Windows are of special interest. <a href="http://msdn.microsoft.com/en-us/library/aa378753(VS.85).aspx">MSV1_0</a> authenticates user credentials against the local SAM database or against a domain controller through the legacy logon protocols. <a href="http://msdn.microsoft.com/en-us/library/aa377942(VS.85).aspx">Kerberos.dll</a> uses the Kerberos protocol with modern domain controllers (or third party KDCs, etc.) for establishing logon sessions.
Applications that want to provide value-added logon functionality wish to become involved in the logon process. Winlogon provides the <a href="http://msdn.microsoft.com/en-us/library/aa380543.aspx">GINA</a> facility before Windows Vista and the new <a href="http://msdn.microsoft.com/en-us/library/bb648647(VS.85).aspx">Credential Providers</a> in Windows Vista and later to allow involvement in the end-user logon experience.
While customizing the logon process is done at the logon application side with GINAs or CPs, sometimes customization is required at the authentication side, in the <a href="http://msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx">Local Security Authority</a> subsystem. For instance, a fingerprint reader may customize the logon UI to allow fingerprint scanning as a means of authentication. The customized logon application will call <a href="http://msdn.microsoft.com/en-us/library/aa378292(VS.85).aspx">LsaLogonUser</a> with the fingerprint scanner’s custom LSA authentication package as the desired authenticator. The fingerprint LSA AP will scan a fingerprint database it maintains to perform the authentication process. That would be an independent LSA authenticaion package.
There are other scenarios in which the regular MSV1_0/Kerberos based logon authentication process is desired, but special pre or post-processing is required. In Windows XP, the problematic GINA architecture makes replacing the GINA cumbersome, as multiple third-party applications may attempt to install conflicting GINA replacements. Indeed, Microsoft documentation has been modified retroactively to recommend <a href="http://msdn.microsoft.com/en-us/library/aa378292(VS.85).aspx">GINA hooks and stubs</a> in lieu of outright replacement of the MSGINA implementation previously suggested.
With the ability to instrument the logon application at the GINA side limited and version dependent (a totally different approach is required for Vista’s CPs), the alternative of instrumentation at the LSA side warrants exploration. We can implement an LSA proxy authentication package. Such a package would appear to the LSA server as an ordinary package, but would be implemented by delegating to original APs like MSV1_0 and Kerberos, providing it with monitoring and instrumentation capabilities.
LSA authentication packages are loaded by LSASS at system startup by enumerating them from the registry value HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages. Both LSA authentication packages (APs) and security providers (SSPs) are registered at that location. For the purposes of this post, we’ll ignore pure SSPs and focus only on APs. We will register our proxy authentication package instead of MSV1_0 (and possibly Kerberos) at this location, and leave loading of the original APs to our proxy AP implementation.
Let us examine the system’s core APs, MSV1_0 and Kerberos: 
<code> 
C:\WINDOWS\system32>dumpbin /exports msv1_0.dll 
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01 
Copyright (C) Microsoft Corporation. All rights reserved. 
Dump of file msv1_0.dll 
File Type: DLL 
Section contains the following exports for msv1_0.dll 
00000000 characteristics 
48025C84 time date stamp Sun Apr 13 22:18:28 2008 
0.00 version 
1 ordinal base 
32 number of functions 
17 number of names 
ordinal hint RVA name 
5 0 0000175C LsaApCallPackage = _LsaApCallPackage@28 
6 1 00014BC8 LsaApCallPackagePassthrough = _LsaApCallPackagePassthr 
ough@28 
7 2 00014A59 LsaApCallPackageUntrusted = _LsaApCallPackageUntrusted 
@28 
8 3 0000BDBB LsaApInitializePackage = _LsaApInitializePackage@20 
9 4 0000F7FE LsaApLogonTerminated = _LsaApLogonTerminated@4 
10 5 00007498 LsaApLogonUserEx2 = _LsaApLogonUserEx2@64 
11 6 0001A7E5 Msv1_0ExportSubAuthenticationRoutine = _Msv1_0ExportSu 
bAuthenticationRoutine@40 
12 7 0001A7C6 Msv1_0SubAuthenticationPresent = _Msv1_0SubAuthenticat 
ionPresent@4 
13 8 00016E63 MsvGetLogonAttemptCount = _MsvGetLogonAttemptCount@0 
2 9 0001B704 MsvIsLocalhostAliases = ?MsvIsLocalhostAliases@@YGHPAU 
_UNICODE_STRING@@@Z (int __stdcall MsvIsLocalhostAliases(struct _UNICODE_STRING 
*)) 
14 A 00016E59 MsvSamLogoff = _MsvSamLogoff@12 
15 B 0000A7BA MsvSamValidate = _MsvSamValidate@52 
16 C 00016E6E MsvValidateTarget = _MsvValidateTarget@12 
1 D 0000E415 SpInitialize = _SpInitialize@12 
32 E 00006BC2 SpInstanceInit = _SpInstanceInit@12 
3 F 0000F08F SpLsaModeInitialize = ?SpLsaModeInitialize@@YGJKPAKPAP 
AU_SECPKG_FUNCTION_TABLE@@0@Z (long __stdcall SpLsaModeInitialize(unsigned long, 
unsigned long *,struct _SECPKG_FUNCTION_TABLE * *,unsigned long *)) 
4 10 00006AE0 SpUserModeInitialize = ?SpUserModeInitialize@@YGJKPAKP 
APAU_SECPKG_USER_FUNCTION_TABLE@@0@Z (long __stdcall SpUserModeInitialize(unsign 
ed long,unsigned long *,struct _SECPKG_USER_FUNCTION_TABLE * *,unsigned long *)) 
Summary 
2000 .data 
2000 .reloc 
2000 .rsrc 
1D000 .text 
C:\WINDOWS\system32>dumpbin /exports kerberos.dll 
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01 
Copyright (C) Microsoft Corporation. All rights reserved. 
Dump of file kerberos.dll 
File Type: DLL 
Section contains the following exports for Kerberos.dll 
00000000 characteristics 
48025C4A time date stamp Sun Apr 13 22:17:30 2008 
0.00 version 
1 ordinal base 
32 number of functions 
10 number of names 
ordinal hint RVA name 
5 0 00026F8A KerbCreateTokenFromTicket = _KerbCreateTokenFromTicket 
@44 
2 1 00025773 KerbDomainChangeCallback = ?KerbDomainChangeCallback@@ 
YGXW4_POLICY_NOTIFICATION_INFORMATION_CLASS@@@Z (void __stdcall KerbDomainChange 
Callback(enum _POLICY_NOTIFICATION_INFORMATION_CLASS)) 
6 2 000018B0 KerbFree = _KerbFree@4 
7 3 00020A71 KerbIsInitialized = _KerbIsInitialized@0 
8 4 00020A7C KerbKdcCallBack = _KerbKdcCallBack@0 
9 5 0000380B KerbMakeKdcCall = _KerbMakeKdcCall@32 
1 6 00013CAD SpInitialize = _SpInitialize@12 
32 7 0000EDDF SpInstanceInit = _SpInstanceInit@12 
3 8 000151DE SpLsaModeInitialize = ?SpLsaModeInitialize@@YGJKPAKPAP 
AU_SECPKG_FUNCTION_TABLE@@0@Z (long __stdcall SpLsaModeInitialize(unsigned long, 
unsigned long *,struct _SECPKG_FUNCTION_TABLE * *,unsigned long *)) 
4 9 0000ED1E SpUserModeInitialize = ?SpUserModeInitialize@@YGJKPAKP 
APAU_SECPKG_USER_FUNCTION_TABLE@@0@Z (long __stdcall SpUserModeInitialize(unsign 
ed long,unsigned long *,struct _SECPKG_USER_FUNCTION_TABLE * *,unsigned long *)) 
Summary 
2000 .data 
3000 .reloc 
3000 .rsrc 
43000 .text</code>
Both DLLs export the <a href="http://msdn.microsoft.com/en-us/library/aa380171(VS.85).aspx">SpInitialize</a> function used for SSP initialization and for AP initialization export <a href="http://msdn.microsoft.com/en-us/library/aa380175(VS.85).aspx">SpLsaModeInitialize</a> and <a href="http://msdn.microsoft.com/en-us/library/aa380185(VS.85).aspx">SpUserModeInitialize</a>, called in LSASS context and in logon application context by secur32.dll, respectively.
As can be seen in MSV1_0’s export table, it provides a <a href="http://msdn.microsoft.com/en-us/library/aa374786(VS.85).aspx">subauthentication package</a> facility for those interested in becoming involved in the logon process. Clearly, this is the facility Microsoft intended third-parties to use, rather than creating proxy authentication packages. Unfortunately, subauthentication packages only provide a subset of authentication package functionality, primarily failing to provide access to the interactive logon (as opposed to the network logon) process. You should carefully consider your requirements. If they can be met with a subauthentication package, it is best to opt for that approach as it is far more likely to remain intact in Windows 7 and beyond. That said, the proxy authentication package model is given some legitimacy by <a href="http://msdn.microsoft.com/en-us/library/aa374784(VS.85).aspx">this diagram</a>, illustrating delegation to MSV1_0 by a hypothetical third-party custom authentication package.
It is interesting to note that MSV1_0 chooses to export the various LSA AP functions, such as LsaApLogonUserEx2, etc., via its DLL export table, while Kerberos opts not to export them, though quick examination of Kerberos.dll’s public symbols clearly illustrates the presence of the AP functions. So how does the LSA server know how to find and call the various AP functions? They are provided in a function dispatch table filled by the AP at initialization time, when <a href="http://msdn.microsoft.com/en-us/library/aa380175(VS.85).aspx">SpLsaModeInitialize</a> or <a href="http://msdn.microsoft.com/en-us/library/aa380185(VS.85).aspx">SpUserModeInitialize</a> are invoked (depending on the context of the AP’s use).
Keeping in mind that MSV1_0 was around before Kerberos was added to Windows NT in the Windows 2000 release and therefore may have remaining legacy cruft, reviewing the disassembly of the LSA server DLL, LSASRV, reveals that LSA first calls the Initialize functions to let the AP fill the function dispatch table, but then promptly examines the AP’s export table with <a href="http://msdn.microsoft.com/en-us/library/ms683212(VS.85).aspx">GetProcAddress</a> in the aptly named lsasrv!BindOldPackage function. This function appears to be invoked for the AP even when the function dispatch table has been filled. However, empirical evidence appears to suggest that the function dispatch table takes precedence over the contents of the export table. Indeed, Kerberos opts to do away with the export table entirely.
It appears that the export-based model was replaced with the dispatch table based model at some point during the lifetime of Windows NT. The export model has an obvious disadvantage of allowing a single DLL to implement only a single authentication package, a restriction will come back to later. The dispatch table model, on the other hand, allows the initialization function to return multiple dispatch tables, for multiple authentication packages, from a single DLL. This may yet prove useful for a proxy package.
In order to explore the feasibility of creating a proxy LSA authentication package, I wrote a test DLL, dubbed “LsaPrxAp”. This DLL provides the <a href="http://msdn.microsoft.com/en-us/library/aa380171(VS.85).aspx">SpInitialize</a>, SpLsaModeInitialize and SpUserModeInitialize exports. When invoked, it loads msv1_0 if it is not yet loaded. The DLL’s Initialize functions call the original msv1_0’s Initialize functions and then hook the authentication package by replacing function pointers with pointers to implementations of the LSA AP functions residing in LSAPrxAp. The original function pointers are saved in a global data structure so that LSAPrxAp’s stubs can invoke them while having value-added processing during the logon sequence. Since the name of the authentication package is the one provided in the SpLsaModeInitialize function by the AP, rather than the DLL’s name, it is easy to proxy the MSV1_0 module and become involved in the logon process. I did not bother with supporting Kerberos in my test, but hypothetically the proxy AP can call the Initialize functions for both MSV1_0 and Kerberos and return two dispatch tables as the parameter model for it allows.
Proxying a known authentication package of a known revision is one thing, but a more generic approach warrants special consideration. In both XP and Vista, the APs provide the latest <a href="http://msdn.microsoft.com/en-us/library/aa378257(VS.85).aspx">LsaApLogonUserEx2 </a>function. However, it is preceeded by <a href="http://msdn.microsoft.com/en-us/library/aa378248(VS.85).aspx">LsaApLogonUserEx</a> and <a href="http://msdn.microsoft.com/en-us/library/aa378244(VS.85).aspx">LsaApLogonUser</a>. The documentation for AP developers seems to indicate it is still legitimate to only support one of the older variants. Therefore, the proxy should take note that NULL function pointers in the dispatch table provided by the original APs are possible and should react accordingly.
As I investigated the behavior of the LSA server with respect to the export-based model for locating LSA AP functions vs. the function dispatch table model, I considered the problem of implementing a generic proxy if the dispatch table model was not preferred over the export table. The proxy AP would have to load the original AP and only have an LsaApLogonUserEx2 function if the original AP has. If the original AP has no <a href="http://msdn.microsoft.com/en-us/library/aa378244(VS.85).aspx">LsaApLogonUser</a> function exported, neither should the proxy AP. This presents special complication since compiling a different proxy AP for every possible set of exports is not feasible. I reiterate that the problem is theoretical since the function dispatch table model has no such fallacy.
In order to deal with this issue, I devised an approach where the proxy AP would initially export all possible LSA AP functions. At runtime, as the actual exports of the original AP is detected, functions that are missing from the original AP can be unexported from the proxy AP. I discuss the technique of unexporting functions through name obfuscation in the <a href="https://kobyk.wordpress.com/2008/08/30/unexporting-a-function-from-a-dll-at-runtime-by-name-obfuscation/">previous post</a>.
Successfully compiling an LSA AP DLL required numerous acts of header juggling. For reference purposes, I provide the sequence I used:
<pre class="brush: cpp; title: ; notranslate">
#include <ntstatus.h>
#define WIN32_NO_STATUS
#include <Windows.h>
#include <NTSecAPI.h>
#define SECURITY_WIN32
#include <SSPI.h>
#ifndef NT_SUCCESS
#define NT_SUCCESS(Status) ((NTSTATUS)(Status) >= 0)
#endif
// LsaApCallPackageUntrusted is partially missing from NTSecPkg.h
typedef NTSTATUS
(NTAPI LSA_AP_CALL_PACKAGE_UNTRUSTED)(
__in PLSA_CLIENT_REQUEST ClientRequest,
__in PVOID ProtocolSubmitBuffer,
__in PVOID ClientBufferBase,
__in ULONG SubmitBufferLength,
__out PVOID* ProtocolReturnBuffer,
__out PULONG ReturnBufferLength,
__out PNTSTATUS ProtocolStatus
);
</pre>
The WIN32_NO_STATUS definition is required to prevent Windows.h from defining the NTSTATUS values. Letting ntstatus.h define them is required because Windows.h only defines a subset of the required values. SSPI.h requires choosing between Win32, Kernel-mode and Macintosh Classic (heh…) usage, resulting in the SECURITY_WIN32 preprocessor definition. The NTSecPkg.h header included with the Windows SDK I’m using makes the embarrassing error of missing the prototype for <a href="http://msdn.microsoft.com/en-us/library/aa378218(VS.85).aspx">LsaApCallPackageUntrusted</a>, while curiously attempting to provide the function pointer type for it.
It is wise to avoid loading the original AP DLLs during DllMain, due to potential loader lock issues. The first functions invoked after an AP DLL has been mapped to a process are those that fill the function dispatch table; SpInitialize for the SSP case, SpLsaModeInitialize for the LSASS-side AP case and SpUserModeInitialize for the secur32.dll logon application (Winlogon) side case. All three functions ought to load the original AP if required and perform any required hooking of the dispatch tables, pointing to your own proxy functions.
The initialization functions should also extract the function pointers for the original AP implementations and preserve them in global data. This can later be used to forward calls to the original implementation. Consider the implementation of LsaApCallPackage in my LsaPrxAp test DLL:
<pre class="brush: cpp; title: ; notranslate">
NTSTATUS NTAPI LsaApCallPackage(
__in PLSA_CLIENT_REQUEST ClientRequest,
__in PVOID ProtocolSubmitBuffer,
__in PVOID ClientBufferBase,
__in ULONG SubmitBufferLength,
__out PVOID* ProtocolReturnBuffer,
__out PULONG ReturnBufferLength,
__out PNTSTATUS ProtocolStatus
)
{
OutputDebugString(TEXT("lsaaprxap LsaApCallPackage\n"));
return g_LsaPrxApFunctionTable.pLsaApCallPackage(
ClientRequest, ProtocolSubmitBuffer, ClientBufferBase,
SubmitBufferLength, ProtocolReturnBuffer, ReturnBufferLength,
ProtocolStatus);
}
</pre>
Obviously a real-world proxy AP would perform required processing before or after forwarding to the original function pointer preserved in global data, as well.
Hopefully this primer on implementing an LSA proxy AP will prove to be a welcome addition to Microsoft’s sparse documentation on LSA authentication packages.
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/08/30/implementing-an-lsa-proxy-authentication-package/feed/</wfw:commentRss>
<slash:comments>21</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Unexporting a function from a DLL at runtime by name obfuscation</title>
<link>https://kobyk.wordpress.com/2008/08/30/unexporting-a-function-from-a-dll-at-runtime-by-name-obfuscation/</link>
<comments>https://kobyk.wordpress.com/2008/08/30/unexporting-a-function-from-a-dll-at-runtime-by-name-obfuscation/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Sat, 30 Aug 2008 14:56:34 +0000</pubDate>
<category><![CDATA[C++]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=32</guid>
<description><![CDATA[Usually, the set of functions exported by a Windows DLL is considered to be immutable. When load-time binding is used, functions appearing in the loading module’s import table are resolved against the export table of the loaded DLL. If any … <a href="https://kobyk.wordpress.com/2008/08/30/unexporting-a-function-from-a-dll-at-runtime-by-name-obfuscation/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[Usually, the set of functions exported by a Windows DLL is considered to be immutable. When load-time binding is used, functions appearing in the loading module’s import table are resolved against the export table of the loaded DLL. If any imported functions are missing, the loader aborts the module load attempt and unmaps the modules.
Library clients which require a more flexible reaction to the presence or absence of specific exports opt for a more dynamic binding approach, either late binding via <a href="http://msdn.microsoft.com/en-us/library/ms683212(VS.85).aspx">GetProcAddress</a> directly or through the Visual C++ <a href="http://msdn.microsoft.com/en-us/library/151kt790.aspx">delay loading</a> facility, which allows for setting callbacks for missing modules or exports.
Recently, as I was experimenting with implementing an LSA proxy authentication package (more on that in a followup post) I considered the issue of properly implementing a proxy DLL for a DLL whose set of exports is only partially known to the proxy. Modern LSA APs have a callback function that provides a function dispatch table and do no rely on the module’s export table, but for pedagogic purposes let us consider an hypothetical situation in which the export table is the only lookup apparatus in use by the LSA.
In the case of an LSA authentication package, the package may provide an implementation of either <a href="http://msdn.microsoft.com/en-us/library/aa378244(VS.85).aspx">LsaApLogonUser</a>, <a href="http://msdn.microsoft.com/en-us/library/aa378248(VS.85).aspx">LsaApLogonUserEx</a> or <a href="http://msdn.microsoft.com/en-us/library/aa378257(VS.85).aspx">LsaApLogonUserEx2</a>. An original LSA AP can export one or more of these functions. If we want to create a generic LSA AP proxy DLL, we may wish to have a specific export from our module, loaded in lieu of the original AP, only if the original module also had it. This presents difficulty since we may not be able to predict the specific set of exports during proxy compile time.
If we recognize that DLL exports are in fact a poor man’s native code reflection mechanism, we can adopt a non-traditional approach of dynamic modification of our module’s set of exported functions. Our proxy DLL shall initially (at compile time) export all functions that could potentially be exported by the original DLL, e.g. by a module definition (.DEF) file like this: 
<code> 
LIBRARY "lsaprxap" 
EXPORTS 
LsaApInitializePackage 
LsaApLogonUser 
LsaApLogonUserEx 
LsaApLogonUserEx2 
LsaApCallPackage 
LsaApCallPackagePassthrough 
LsaApLogonTerminated 
LsaApCallPackageUntrusted 
SpInitialize 
SpInstanceInit 
SpLsaModeInitialize 
SpUserModeInitialize</code>
Notice how we export all three functions, even though some may not appear in the original DLL. LSA uses late binding via GetProcAddress to decide which function in the AP to call. If we export LsaApLogonUserEx2 and our original DLL does not have that function, we’ll have nothing to do when our proxy function is called (no original to forward to after our own processing). There is no telling what will happen if we return STATUS_NOT_IMPLEMENTED. Besides, LSA AP’s are only an illustration, and in other cases the export might not even have the option to return a failure exit code. Therefore, the behavior we desire is that GetProcAddress for LsaApLogonUserEx2 will fail and return NULL if the original DLL for which we are acting as a proxy does not export LsaApLogonUserEx2 itself.
The names and addresses of exported functions from a DLL appear in the PE image’s export directory. By accessing the export directory, looking up an exported function of interest and removing it we can alter the behavior of GetProcAddress for the exported function at runtime, after the module has been loaded. Note that this alteration is only useful for GetProcAddress invocations from that time forward, and callers that invoked GetProcAddress earlier and cached the result or callers that used load-time binding against our export table already obtained a function pointer to the exported function. Therefore, this technique is only useful in limited circumstances.
The export directory points to a block of null-terminated string pointers, indexed by export ordinal. In order to outright remove an export from the middle of the export table, we’d have to copy the export table aside, remove the desired functions and point the PE header to the new export table. This is a feasible, but cumbersome approach. Instead I opted for an alternative technique – obfuscating the name of the export to prevent GetProcAddress callers from resolving it by its well-known name. The function is still exported, but its name is unknown to other callers. This is probably sufficient for the vast majority of cases. As for the obfuscation itself, in this illustration we’ll merely increment the character value of the first letter in the export:
<pre class="brush: cpp; title: ; notranslate">
// Set by the linker to the base address of the module.
EXTERN_C IMAGE_DOS_HEADER __ImageBase;
void UnexportFunction(LPSTR ExportName)
{
IMAGE_DOS_HEADER* dosHeader = &__ImageBase;
assert(dosHeader->e_magic == IMAGE_DOS_SIGNATURE);
IMAGE_NT_HEADERS* ntHeaders = reinterpret_cast<IMAGE_NT_HEADERS*>(
reinterpret_cast<BYTE*>(dosHeader) + dosHeader->e_lfanew);
assert(ntHeaders->Signature == 0x00004550);
IMAGE_OPTIONAL_HEADER* optionalHeader = &ntHeaders->OptionalHeader;
IMAGE_DATA_DIRECTORY* exportDataDirectory =
&optionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];
IMAGE_EXPORT_DIRECTORY* exportDirectory = reinterpret_cast<IMAGE_EXPORT_DIRECTORY*>(
reinterpret_cast<BYTE*>(dosHeader) + exportDataDirectory->VirtualAddress);
ULONG* addressOfNames = reinterpret_cast<ULONG*>(
reinterpret_cast<BYTE*>(dosHeader) + exportDirectory->AddressOfNames);
for (DWORD i = 0; i < exportDirectory->NumberOfFunctions; i++)
{
LPSTR exportFunctionName = reinterpret_cast<LPSTR>(
reinterpret_cast<BYTE*>(dosHeader) + addressOfNames[i]);
if (strcmp(exportFunctionName, ExportName) == 0)
{
DWORD oldProtect = 0;
BOOL rc = VirtualProtect(
exportFunctionName,
strlen(exportFunctionName),
PAGE_READWRITE,
&oldProtect);
if (rc == FALSE)
{
OutputDebugString(TEXT("VirtualProtect failed.\n"));
}
exportFunctionName[0]++;
break;
}
}
}
</pre>
The sample UnexportFunction function iterates over the current module’s export table until the function of interest is encountered. Since the export table is mapped as read-only memory, <a href="http://msdn.microsoft.com/en-us/library/aa366898(VS.85).aspx">VirtualProtect </a>must be used to allow for its modification. The string containing the name of the exported function is modified in place as a trivial obfuscation. This is sufficient to result in the “unexporting” of the symbol:
<pre class="brush: cpp; title: ; notranslate">
FARPROC before = GetProcAddress((HMODULE)&__ImageBase, "LsaApLogonUser");
UnexportFunction("LsaApLogonUser");
FARPROC after = GetProcAddress((HMODULE)&__ImageBase, "LsaApLogonUser");
assert(before != after);
assert(after == NULL);
</pre>
With this tool of export entry removal at our disposal, we can devise an architecture in which the proxy DLL contains all exports that are feasible to be present in the original DLL at runtime. Through “reflection” of the original DLL, the proxy shall determine which redundant exports it wishes to hide, resulting it runtime behavior consistent with that of the original DLL (again, assuming only late binding with GetProcAddress is used).
What if we are unable to construct a superset of all possible exports from the original DLL? Perhaps we wish to be future-proof as new, unknown exports are added to the original DLL. For that a variety of solutions may be considered. In particular, copying the original DLL’s export table to our own and inserting hooks as needed comes to mind. Perhaps a topic for a future post…
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/08/30/unexporting-a-function-from-a-dll-at-runtime-by-name-obfuscation/feed/</wfw:commentRss>
<slash:comments>3</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Debugging user-mode BootExecute native applications with kd</title>
<link>https://kobyk.wordpress.com/2008/07/26/debugging-user-mode-bootexecute-native-applications-with-kd/</link>
<comments>https://kobyk.wordpress.com/2008/07/26/debugging-user-mode-bootexecute-native-applications-with-kd/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Sat, 26 Jul 2008 14:25:48 +0000</pubDate>
<category><![CDATA[Windbg]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=26</guid>
<description><![CDATA[Debugging code executing during system startup always poses a unique challenge. One may need to debug a custom or built-in Windows service right from the start, when attaching to it after it has initialized proves insufficient or inappropriate. When developing … <a href="https://kobyk.wordpress.com/2008/07/26/debugging-user-mode-bootexecute-native-applications-with-kd/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[Debugging code executing during system startup always poses a unique challenge. One may need to debug a custom or built-in Windows service right from the start, when attaching to it after it has initialized proves insufficient or inappropriate. When developing a <a href="http://msdn.microsoft.com/en-us/library/aa375198(VS.85).aspx#hook">GINA hook</a> or <a href="http://msdn.microsoft.com/en-us/library/aa375198(VS.85).aspx#stub">GINA stub</a>, the need to debug the Winlogon process before the logon process is performed arises. The inability of the Visual Studio Debugger to be useful in these situations is one of the reasons people turn to Windbg.
For debugging Windows services or the Winlogon process during startup, <a href="http://msdn.microsoft.com/en-us/library/cc267855.aspx">Image File Execution Options </a>provides a workable solution. As soon as a process of the name specified under the Image File Execution Options registry key is created, the debugger command-line specified in the Debugger value is executed in lieu of the original command-line, which is appended to the debugger command-line. The debugger started might be Visual Studio’s, if appropriate, an interactive Windbg in other cases or an NTSD remote debugging server when you will not or cannot do things like make the service process interactive.
For the vast majority of startup applications, the aforementioned technique is both quite sufficient and convenient. However, there is another, perhaps esoteric, category of startup processes. These run a very early stage of the boot process. They are the <a href="http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/46697.mspx?mfr=true">BootExecute</a> applications.
BootExecute applications are started by the Session Manager (smss.exe) before invoking the “initial command” (Winlogon in XP) and before the various subsystems are started. As far as user-mode goes, it doesn’t get much earlier than this. Because of their early nature, a significant constraint is in place for BootExecute applications: they are native applications.
Do not confuse this usage of “native” with native code vs. .NET managed code. In this context, native means that only the Windows NT Native API, resident in ntdll.dll, is available. At this stage, the Win32 subsystem, composed of the kernel-mode win32k.sys component and the user-mode client/server runtime, CSRSS, have not yet been started by SMSS. Not even the Kernel32 library is usable by BootExecute applications.
What are these useful for? Those special tasks that must be performed before everything else has started in the system, yet remain in the domain of user-mode work. Consider these two typical examples:
<ul>
<li>AutoCheck, the BootExecute variant of the CHKDSK tool, used to examine the boot volume before it is locked and to fix critical file-system errors.</li>
<li>Sysinternals PageDefrag, a BootExecute utility that defragments the Paging File, registry hives and other files inaccessible to defragging by the normal Win32 Disk Defragmentation tool.</li>
</ul>
We can confirm that AutoCheck is indeed a native application by examining it with Visual C++’s DUMPBIN utility: 
<code> 
C:\WINDOWS\system32>dumpbin /headers autochk.exe 
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08 
Copyright (C) Microsoft Corporation. All rights reserved. 
</code><code> 
Dump of file autochk.exe 
</code><code> 
PE signature found 
</code><code> 
File Type: EXECUTABLE IMAGE 
</code><code> 
FILE HEADER VALUES 
14C machine (x86) 
4 number of sections 
48025203 time date stamp Sun Apr 13 21:33:39 2008 
0 file pointer to symbol table 
0 number of symbols 
E0 size of optional header 
10E characteristics 
Executable 
Line numbers stripped 
Symbols stripped 
32 bit word machine 
</code><code> 
OPTIONAL HEADER VALUES 
10B magic # (PE32) 
7.10 linker version 
5B800 size of code 
34200 size of initialized data 
0 size of uninitialized data 
D6B9 entry point (0100D6B9) _NtProcessStartupForGS@4 
1000 base of code 
5D000 base of data 
1000000 image base (01000000 to 01091FFF) 
1000 section alignment 
200 file alignment 
5.01 operating system version 
5.01 image version 
5.01 subsystem version 
0 Win32 version 
92000 size of image 
400 size of headers 
96A6F checksum 
1 subsystem (Native) 
0 DLL characteristics 
40000 size of stack reserve 
1000 size of stack commit 
100000 size of heap reserve 
1000 size of heap commit 
0 loader flags 
10 number of directories 
... snipped ...</code>
Notice the subsystem specified for AutoChk is the native subsystem. Notice further that the application’s entrypoint is NtProcessStartup (in its /GS compiler stack buffer overflow protection stub form).
As for PageDefrag, it takes advantage of the Session Manager running its BootExecute application before it has enabled use of the Paging File.
You may find reasons of your own to develop a BootExecute native application, or you may find yourself in a situation requiring debugging of an existing BootExecute application. For instance, you may wish to debug the interactions of AutoChk’s volume locking attempts with your file system filter driver.
Unfortunately, these native applications pose a special difficulty to the user-mode debugger. NTSD is a Win32 application and must be invoked only after the Win32 subsystem has been initialized. Therefore, invocation of NTSD for debugging BootExecute applications is out of the question. Indeed, it is quite likely the Image File Execution Options registry key is not even consulted for BootExecute invocations, as that would be quite pointless.
Theoretically, this problem could be addressed by the development of a native subsystem user mode debugger, in lieu of the Win32-based NTSD. <a href="http://www.alex-ionescu.com/">Alex Ionescu</a>, most recently contributing to the eagerly awaited <a href="http://www.microsoft.com/mspress/books/12069.aspx">5th edition of the Windows Internals book</a>, has discussed the specifics of the NT Native Debugging API (DbgUi, etc.) in a series of articles titled <a href="http://www.openrce.org/articles/full_view/24">Windows Native Debugging Internals</a>.
At the moment, however, I am unaware of any available native subsystem user mode debugger. Such a tool may or may not be available internally in Microsoft. Presumably the Windows developers would benefit from such functionality, but they might also be content with using the kernel debugger for those purposes.
Be that as it may, the rest of us must turn to the kernel debugger for resolution. The kernel debugger can be used for source-level debugging of user-mode applications, including native subsystem applications. The special difficulty with using it is getting to break in the right place at the right time. In lieu of a Image File Execution Options-style apparatus, an alternative approach is required.
When modifying the native BootExecute application in question is feasible, the simple approach of adding an invocation of ntdll’s <a href="http://msdn.microsoft.com/en-us/library/ms792809.aspx">DbgBreakPoint</a> API to the top of the NtProcessStartup process entrypoint is probably the quickest way to get the desired effect. In the absence of a user-mode debugger, the debug break will make its way to the kernel debugger. The debugger will notice the presence of the user-mode module, load symbols and source and the usual debugger functions will be accessible. If source is not available, in many cases the image can be patched to contain either an invocation of DbgBreakPoint or just an inline INT 3, as appropriate.
Such an approach, however, may not be feasible at all times and has the significant disadvantage of making the modified native application hang when a kernel debugger is not attached to the system at boot. Ideally, we’d like to break at process startup without modifying the native application at all.
When using the user-mode debugger, “sxe ld” can break when user-mode modules are mapped by the loader, as documented in <a href="http://msdn.microsoft.com/en-us/library/cc266379.aspx">Controlling Exceptions and Events</a>. Normally, the kernel debugger does not provide that capability. However, it turns out that it can do so, once appropriately configured.
Before booting with the kernel debugger, turn on the “<a href="http://msdn.microsoft.com/en-us/library/cc265929.aspx">Enable loading of kernel debugger symbols</a>” Global Flag, using the GFlags utility bundled with the Debugging Tools for Windows: 
<code> 
C:\Program Files\Debugging Tools for Windows>gflags /r +ksl 
Current Boot Registry Settings are: 00040000 
ksl - Enable loading of kernel debugger symbols</code>
Although the name and description of this Global Flag appear to have nothing to do with user-mode module load events in the kernel debugger, they acheive the desired effect. Once enabled, we can reboot with the kernel debugger attached and ask for the kernel debugger to break once the desired native application is mapped: 
<code> 
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86 
Copyright (c) Microsoft Corporation. All rights reserved. 
</code><code> 
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE 
Kernel Debugger connection established. (Initial Breakpoint requested) 
Symbol search path is: C:\WINDOWS\Symbols;SRV*E:\SymStore*http://referencesource.microsoft.com/symbols;SRV*E:\SymStore*http://msdl.microsoft.com/download/symbols 
Executable search path is: 
Windows XP Kernel Version 2600 MP (1 procs) Free x86 compatible 
Built by: 2600.xpsp.080413-2111 
Kernel base = 0x804dc000 PsLoadedModuleList = 0x805684c0 
System Uptime: not available 
Break instruction exception - code 80000003 (first chance) 
... snipped breakpoint warning message ... 
nt!RtlpBreakWithStatusInstruction: 
804e7a42 cc int 3 
kd> sxe ld:autochk 
kd> g 
nt!DebugService2+0x10: 
8050ae56 cc int 3</code>
Setting the kernel debugger to break on the load of the AutoChk native BootExecute application resulted in our desired break. Let us consider the context of this break: 
<code> 
0: kd> kb 
ChildEBP RetAddr Args to Child 
f738d9fc 8050b2f9 f738da40 f738da10 00000003 nt!DebugService2+0x10 
f738da20 805c533a f738da40 01000000 82953020 nt!DbgLoadImageSymbols+0x42 
f738da70 805c51f0 82ab9c28 01000000 82953020 nt!MiLoadUserSymbols+0x169 
f738dab4 8058d013 82ab9c28 01000000 f738db5c nt!MiMapViewOfImageSection+0x4b6 
f738db10 80504e27 00000004 82953110 f738db5c nt!MmMapViewOfSection+0x13c 
f738db6c 80590520 e165ec14 00000000 e1412398 nt!MmInitializeProcessAddressSpace+0x33d 
f738dcbc 8059082f 0015f870 001f0fff 0015f7d8 nt!PspCreateProcess+0x333 
f738dd10 805b54b2 0015f870 001f0fff 0015f7d8 nt!NtCreateProcessEx+0x7e 
f738dd3c 804e298f 0015f870 001f0fff 0015f7d8 nt!NtCreateProcess+0x3d 
f738dd3c 7c90e4f4 0015f870 001f0fff 0015f7d8 nt!KiFastCallEntry+0xfc 
WARNING: Frame IP not in any known module. Following frames may be wrong. 
0015f830 00000000 00000000 00000000 00000000 0x7c90e4f4 
0: kd> !process 0 0 
**** NT ACTIVE PROCESS DUMP **** 
PROCESS 82bc9830 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 
DirBase: 02f40000 ObjectTable: e1002e40 HandleCount: 46. 
Image: System 
</code><code> 
PROCESS 82935128 SessionId: none Cid: 0218 Peb: 7ffd9000 ParentCid: 0004 
DirBase: 0899b000 ObjectTable: e13fbc68 HandleCount: 7. 
Image: smss.exe</code>
Although AutoChk has been mapped into memory, the AutoChk process is still in the process of being created. Indeed, the AutoChk process is as of yet absent from the system process list displayed by the <a href="http://msdn.microsoft.com/en-us/library/cc267076.aspx">!process</a> debugger extension command.
However, AutoChk’s pseudo-created state does not prevent us from taking this opportunity to set up a debug breakpoint at the top of user code: 
<code> 
1: kd> lm m autochk 
start end module name 
01000000 01092000 autochk (deferred) 
1: kd> bp autochk!NtProcessStartup 
1: kd> bl 
0 e 0100dd3d 0001 (0001) autochk!NtProcessStartup</code>
Beware that if you perform a symbol reload with the <a href="http://msdn.microsoft.com/en-us/library/cc266830.aspx">.reload</a> command after the module load event for autochk has fired off, you may find that it has disappeared from the debugger’s loaded module list… Just make sure you set up your breakpoint immediately after the event break.
It is easy enough to set a breakpoint at the application’s NtProcessStartup entrypoint before the EPROCESS is available, but we may wish to to set early breakpoints in process context elsewhere. To that end, we may proceed to the return from the process creation API from the module load event break, until the process is listed in the system process list: 
<code> 
1: kd> k 
ChildEBP RetAddr 
f7b619fc 8050b2f9 nt!DebugService2+0x10 
f7b61a20 805c533a nt!DbgLoadImageSymbols+0x42 
f7b61a70 805c51f0 nt!MiLoadUserSymbols+0x169 
f7b61ab4 8058d013 nt!MiMapViewOfImageSection+0x4b6 
f7b61b10 80504e27 nt!MmMapViewOfSection+0x13c 
f7b61b6c 80590520 nt!MmInitializeProcessAddressSpace+0x33d 
f7b61cbc 8059082f nt!PspCreateProcess+0x333 
f7b61d10 805b54b2 nt!NtCreateProcessEx+0x7e 
f7b61d3c 804e298f nt!NtCreateProcess+0x3d 
f7b61d3c 7c90e4f4 nt!KiFastCallEntry+0xfc 
0015f830 00000000 ntdll!KiFastSystemCallRet 
1: kd> gu; gu; gu; gu; gu; gu; gu 
nt!NtCreateProcessEx+0x7e: 
8059082f e87a76f5ff call nt!_SEH_epilog (804e7eae) 
1: kd> !process 0 0 
**** NT ACTIVE PROCESS DUMP **** 
PROCESS 82bc9830 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 
DirBase: 02f40000 ObjectTable: e1002e40 HandleCount: 46. 
Image: System 
</code><code> 
PROCESS 829b4128 SessionId: none Cid: 0228 Peb: 7ffd7000 ParentCid: 0004 
DirBase: 08bbb000 ObjectTable: e1468f58 HandleCount: 8. 
Image: smss.exe 
</code><code> 
PROCESS 8294a3d0 SessionId: none Cid: 0238 Peb: 7ffd6000 ParentCid: 0228 
DirBase: 08d40000 ObjectTable: e13fd408 HandleCount: 0. 
Image: autochk.exe</code>
By examining our location in the call stack after the module load event fires, we can see that returning from the Process Manager’s process creation routine PspCreateProcess would require going up 7 times. With that routine’s execution completed, the EPROCESS for autochk is now listed in the system process list and its value can be used as a context parameter for breakpoint commands, etc.
With the breakpoint on the native entrypoint in place, we can resume system execution and have the kernel debugger land right where we want it: 
<code> 
1: kd> g 
Breakpoint 0 hit 
autochk!NtProcessStartup: 
001b:0100dd3d 8bff mov edi,edi 
1: kd> kb 
ChildEBP RetAddr Args to Child 
0006fff4 00000000 7ffde000 000000c8 0000010a autochk!NtProcessStartup 
1: kd> .process 
Implicit process is now 82935020 
1: kd> .thread 
Implicit thread is now 8293f020</code>
From this point, convenient source debugging of the native application is also possible if it’s your own custom written application. The various features such as Locals, Watches, single stepping, etc., work as expected. Some quirks of kernel debugging of a user process should be taken into consideration (make sure breakpoints have an EPROCESS and ETHREAD context specified when appropriate to avoid venturing into other processes by accident, etc.) and the inaccessibility of some user-mode debugger extension commands may prove inconvenient.
Sure beats DbgPrints, though!
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/07/26/debugging-user-mode-bootexecute-native-applications-with-kd/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
<item>
<title>Replacing boot load drivers with the Windows Boot Debugger</title>
<link>https://kobyk.wordpress.com/2008/07/04/replacing-boot-load-drivers-with-the-windows-boot-debugger/</link>
<comments>https://kobyk.wordpress.com/2008/07/04/replacing-boot-load-drivers-with-the-windows-boot-debugger/#comments</comments>
<dc:creator><![CDATA[Koby Kahane]]></dc:creator>
<pubDate>Fri, 04 Jul 2008 20:03:12 +0000</pubDate>
<category><![CDATA[Kernel]]></category>
<category><![CDATA[Windbg]]></category>
<guid isPermaLink="false">http://kobyk.wordpress.com/?p=25</guid>
<description><![CDATA[Recently, I’ve been assigned to work on fixing several bugs in a Windows file system filter driver. Debugging native code has always been characterized by the tedious and cumbersome modify, compile and link, copy, run, repeat… cycle, but in the … <a href="https://kobyk.wordpress.com/2008/07/04/replacing-boot-load-drivers-with-the-windows-boot-debugger/">Continue reading →</a>]]></description>
<content:encoded><![CDATA[Recently, I’ve been assigned to work on fixing several bugs in a Windows file system filter driver. Debugging native code has always been characterized by the tedious and cumbersome modify, compile and link, copy, run, repeat… cycle, but in the case of kernel-mode development, the overhead of that cycle is even more acute.
I’ve found that booting the target system or virtual machine every time you want to replace a driver file with an updated build and then rebooting to have the new driver loaded significantly prolongs the cycle. Therefore, I was happy to discover Windbg’s <a href="http://msdn.microsoft.com/en-us/library/cc266813.aspx">.kdfiles</a> command.
The .kdfiles command configure’s the kernel debugger’s driver replacement map. Whenever the NT Memory Manager attempts to load a driver image, it consults the kernel debugger, if attached, asking it for an alternative driver image. If the debugger has one, it is transmitted over the kernel debugging connection from the host to the target, and used in lieu of the target’s local driver image.
Using the driver replacement map makes it easier to replace a driver with an updated version. However, in its usual form, the replacement map feature has a significant limitation – it cannot replace boot load drivers.
To understand the logic behind this restriction, one must consider the nature of boot driver loading. While demand-start drivers are started by the user-mode Service Control Manager (SCM) and system-start drivers are loaded by NTOSKRNL’s IoInitSystem function, boot drivers are, as their name suggests, required for the system to boot and are therefore loaded by osloader, a part of ntldr (this description is for pre-Vista systems).
By the time the NT kernel is up and its Memory Manager consults the kernel debugger and its driver replacement map, it is far too late to do anything about those drivers which have been pre-loaded by the OS loader. The initial breakpoint offered by the kernel debugger is simply too late.
Fortunately, Microsoft recognized the importance of providing a driver replacement map for boot load drivers and provides a somewhat esoteric solution in the form of the debug version of NTLDR.
The debug version of NTLDR expects the kernel debugger to attach to it during system startup. Unlike the kernel debugger, it is not configured with the boot.ini file and is always configured to a 115,200 baud connection on the COM1 serial port.
The documentation for .kdfiles points out that the Windows Driver Kit (WDK) bundles a debug version of NTLDR in the debug subdirectory. However, such a file is nowhere to be found there, probably because the WDK now contains the Vista checked kernel in its debug directory and the modern Vista boot loader is distinct from NTLDR. More on Windows Vista later, but for now let’s concentrate on Windows XP.
Failing to locate the debug NTLDR in the WDK, I turned back in time to the Windows Server 2003 SP1 IFS Kit, a variant of the Windows Server 2003 SP1 DDK for file system and file system filter developers. I was glad to find the ntldr_dbg file in its debug subdirectory.
However, my happiness quickly turned to disappointment when I replaced the original NTLDR with ntldr_dbg in a Windows XP virtual machine. The system refused to boot, claiming that NTLDR was corrupt. Since the debug directory in the IFS kit contains checked kernel binaries for Windows Server 2003 SP1, I figured that the provided version of ntldr_dbg is a match for that version, as well.
I turned to the archives, so to speak, and dusted off old MSDN Subscription CDs. I eventually turned up the rather antiquated Windows XP SP1 DDK. In there, I found another version of ntldr_dbg. I placed it as required and this time the system booted successfully.
It is unfortunate that one has to dig up the DDK of yore to locate the boot debugger. It really ought to be more accessible.
With the debug version of NTLDR is in place, when you boot the system, right before the OS loader menu appears, you see the following message: 
<code>Boot Debugger Using: COM1 (Baud Rate 115200)</code>
Once the message is displayed, NTLDR blocks waiting for a kernel debugger to connect. I start the kernel debugger the way I’d usually start it: 
<code>windbg -b -k com:pipe,port=\\.\pipe\com_1</code>
Soon enough, however, it is evident that this is no ordinary kernel debugging session: 
<code> 
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86 
Copyright (c) Microsoft Corporation. All rights reserved.</code> 
<code> 
Opened \\.\pipe\com_1 
Waiting to reconnect... 
BD: Boot Debugger Initialized 
Connected to Windows Boot Debugger 2600 x86 compatible target, ptr64 FALSE 
Kernel Debugger connection established. (Initial Breakpoint requested) 
Symbol search path is: C:\WINDOWS\Symbols;SRV*E:\SymStore*http://referencesource.microsoft.com/symbols;SRV*E:\SymStore*http://msdl.microsoft.com/download/symbols 
Executable search path is: 
Module List address is NULL - debugger not initialized properly. 
WARNING: .reload failed, module list may be incomplete 
KdDebuggerData.KernBase < SystemRangeStart 
Windows Boot Debugger Kernel Version 2600 UP Checked x86 compatible 
Primary image base = 0x00000000 Loaded module list = 0x00000000 
System Uptime: not available 
Break instruction exception - code 80000003 (first chance) 
0041cf70 cc int 3 
kd></code>
Windbg has attached to the Windows Boot Debugger, a debugging environment provided by the debug version of NTLDR at a very early stage of system startup, well before the NT kernel has been loaded. Indeed, the initial breakpoint at the boot debugger occurs before an OS to start has been selected at the loader boot menu.
With the boot debugger at its initial breakpoint, we can set up the driver replacement map as desired. For instance, we can replace NTFS and NDIS with their counterparts from the checked build of Windows XP: 
<code> 
kd> .kdfiles -m \WINDOWS\system32\drivers\Ntfs.sys C:\Stuff\xpsp3checked\Ntfs.sys 
Added mapping for '\WINDOWS\system32\drivers\Ntfs.sys' 
kd> .kdfiles -m \WINDOWS\system32\drivers\Ndis.sys C:\Stuff\xpsp3checked\Ndis.sys 
Added mapping for '\WINDOWS\system32\drivers\Ndis.sys' 
kd> g 
BD: osloader.exe base address 00400000 
BD: \WINDOWS\system32\NTKRNLMP.CHK base address 80A02000 
BD: \WINDOWS\system32\HALMACPI.CHK base address 80100000 
BD: \WINDOWS\system32\KDCOM.DLL base address 80010000 
BD: \WINDOWS\system32\BOOTVID.dll base address 80001000 
BD: \WINDOWS\system32\DRIVERS\ACPI.sys base address 8014C000 
BD: \WINDOWS\system32\DRIVERS\WMILIB.SYS base address 80007000 
BD: \WINDOWS\system32\DRIVERS\pci.sys base address 80062000 
BD: \WINDOWS\system32\DRIVERS\isapnp.sys base address 80012000 
BD: \WINDOWS\system32\DRIVERS\compbatt.sys base address 80009000 
BD: \WINDOWS\system32\DRIVERS\BATTC.SYS base address 8000C000 
BD: \WINDOWS\system32\DRIVERS\intelide.sys base address 8001C000 
BD: \WINDOWS\system32\DRIVERS\PCIIDEX.SYS base address 8017A000 
BD: \WINDOWS\System32\Drivers\MountMgr.sys base address 80181000 
BD: \WINDOWS\system32\DRIVERS\ftdisk.sys base address 8018C000 
BD: \WINDOWS\System32\drivers\dmload.sys base address 8001E000 
BD: \WINDOWS\System32\drivers\dmio.sys base address 801AB000 
BD: \WINDOWS\System32\Drivers\PartMgr.sys base address 801D1000 
BD: \WINDOWS\System32\Drivers\VolSnap.sys base address 801D6000 
BD: \WINDOWS\system32\DRIVERS\atapi.sys base address 801E3000 
BD: \WINDOWS\system32\DRIVERS\vmscsi.sys base address 80073000 
BD: \WINDOWS\system32\DRIVERS\SCSIPORT.SYS base address 801FB000 
BD: \WINDOWS\system32\DRIVERS\disk.sys base address 80213000 
BD: \WINDOWS\system32\DRIVERS\CLASSPNP.SYS base address 8021C000 
BD: \WINDOWS\system32\drivers\fltmgr.sys base address 80229000 
BD: \WINDOWS\system32\DRIVERS\sr.sys base address 802A7000 
BD: \WINDOWS\System32\Drivers\KSecDD.sys base address 802B9000 
KD: Accessing 'C:\Stuff\xpsp3checked\Ntfs.sys' (\WINDOWS\System32\Drivers\Ntfs.sys) 
File size 814K.... ....BD: Loaded remote file \WINDOWS\System32\Drivers\Ntfs.sys 
</code><code> 
BlLoadImageEx: Pulled \WINDOWS\System32\Drivers\Ntfs.sys from Kernel Debugger 
BD: \WINDOWS\System32\Drivers\Ntfs.sys base address 802D0000 
KD: Accessing 'C:\Stuff\xpsp3checked\Ndis.sys' (\WINDOWS\System32\Drivers\NDIS.sys) 
File size 424K.... ....BD: Loaded remote file \WINDOWS\System32\Drivers\NDIS.sys 
</code><code> 
BlLoadImageEx: Pulled \WINDOWS\System32\Drivers\NDIS.sys from Kernel Debugger 
BD: \WINDOWS\System32\Drivers\NDIS.sys base address 804DC000 
Shutdown occurred...unloading all symbol tables. 
Waiting to reconnect.</code>
We can see that the boot debugger picked up our driver replacements and transferred them from the host to the target through the kernel debugger connection. Alas, this can be a lengthy process for an obese driver over the 115,200 baud link…
Beyond being useful for replacing your own drivers, which is what I had in mind when I looked into this feature, the boot debugger can be used to easily go back and forth between Windows free build and checked build operating system components, as illustrated above. However, such use is not without its problems.
For one, replacing the kernel and the HAL with their checked counterparts through the driver replacement map does not work. An error citing kernel corruption results from such an attempt. The traditional way of using a checked kernel, by placing an appropriate entry in boot.ini, is still required.
When testing a file system filter driver, apart from using the checked version of the I/O Manager through the use of the checked NT kernel, it is advantageous to use checked versions of underlying file system drivers such as NTFS. The checked versions can assert when you pass on requests to them in a way which violates the file system’s locking hierarchy and which may lead to deadlocks. Replacing the NTFS driver with the driver replacement map feature worked as expected, apart from causing NDIS to bugcheck during system boot with some sort of paging error. The issue was resolved by replacing NDIS with its checked counterpart through the driver replacement map, as well.
However, for a reason I do not understand, when placing the checked build of the Filter Manager, useful for debugging file system minifilters, there was no such luck. The boot loader complained after transferring the checked Filter Manager that the NTFS driver was corrupt. I disabled System File Protection and replaced the free drivers with the checked drivers on disk, the traditional way and the system booted with the checked NTFS and Filter Manager successfully. So it appears that the boot-time driver replacement map feature can be a bit flaky…
It is probably best to place checked operating system components the traditional way and only replace your own, frequently modified drivers with the boot debugger and the driver replacement map.
So much for Windows XP and the legacy NTLDR. But what about Windows Vista?
At first, the situation looked promising. In Windows Vista, the boot debugger is built-in. It can, for instance, be enabled for an existing boot entry with the Boot Configuration Database editor from an elevated command prompt: 
<code> 
C:\Windows\system32>bcdedit /enum 
</code><code> 
Windows Boot Manager 
-------------------- 
identifier {bootmgr} 
device partition=C: 
description Windows Boot Manager 
locale en-US 
inherit {globalsettings} 
default {current} 
displayorder {current} 
{5761b19a-1e8a-11dd-bcd4-000c29797dc6} 
toolsdisplayorder {memdiag} 
timeout 30 
</code><code> 
Windows Boot Loader 
------------------- 
identifier {current} 
device partition=C: 
path \Windows\system32\winload.exe 
description Microsoft Windows Vista 
locale en-US 
inherit {bootloadersettings} 
osdevice partition=C: 
systemroot \Windows 
resumeobject {694d30db-e737-11dc-814f-e01223f3682a} 
nx OptIn 
</code><code> 
Windows Boot Loader 
------------------- 
identifier {5761b19a-1e8a-11dd-bcd4-000c29797dc6} 
device partition=C: 
path \Windows\system32\winload.exe 
description Debugging 
locale en-US 
inherit {bootloadersettings} 
osdevice partition=C: 
systemroot \Windows 
resumeobject {694d30db-e737-11dc-814f-e01223f3682a} 
nx OptIn 
debug Yes 
</code><code> 
C:\Windows\system32>bcdedit /bootdebug {5761b19a-1e8a-11dd-bcd4-000c29797dc6} ON 
</code><code> 
The operation completed successfully.</code>
Unlike the XP boot debugger, the Vista boot debugger is set for a specific boot loader menu entry. Once we reboot and pick the entry for which boot debugging is enabled, we can attach: 
<code> 
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86 
Copyright (c) Microsoft Corporation. All rights reserved. 
</code><code> 
Opened \\.\pipe\com_1 
Waiting to reconnect... 
BD: Boot Debugger Initialized 
Connected to Windows Boot Debugger 6001 x86 compatible target, ptr64 FALSE 
Kernel Debugger connection established. (Initial Breakpoint requested) 
Symbol search path is: C:\WINDOWS\Symbols;SRV*E:\SymStore*http://referencesource.microsoft.com/symbols;SRV*E:\SymStore*http://msdl.microsoft.com/download/symbols 
Executable search path is: 
Windows Boot Debugger Kernel Version 6001 UP Free x86 compatible 
Primary image base = 0x00584000 Loaded module list = 0x00684e78 
System Uptime: not available 
Break instruction exception - code 80000003 (first chance) 
winload!RtlpBreakWithStatusInstruction: 
005bce88 cc int 3 
kd> k 
ChildEBP RetAddr 
00120c6c 005b0862 winload!RtlpBreakWithStatusInstruction 
00120e84 005b0760 winload!vDbgPrintExWithPrefixInternal+0x100 
00120e94 0058bdaf winload!DbgPrint+0x11 
00120eb0 0058bf6d winload!BlBdStart+0x81 
00120f48 005a2f88 winload!BlBdInitialize+0x172 
00120f64 005a28c2 winload!InitializeLibrary+0x168 
00120f7c 0058513a winload!BlInitializeLibrary+0x42 
00120fe8 0044646a winload!OslMain+0x13a 
WARNING: Frame IP not in any known module. Following frames may be wrong. 
00000000 f000ff53 0x44646a 
00000000 00000000 0xf000ff53</code>
We can see that in Vista, the boot debugger’s initial break is in the new winload.exe, replacing the osloader.exe embedded in ntldr of yesteryear. At this point the boot load drivers have yet to be loaded, so it would be perfect to set the .kdfiles driver replacement map at this point.
Alas, no such luck. It turns out the boot load driver replacement map feature is MIA in Windows Vista. This is confirmed by Microsoft’s Doron Holan in a <a href="http://www.osronline.com/showThread.cfm?link=108173">reply to a post</a> (free registration required) in OSR’s WINDBG mailing list. It is unclear what is the point of bundling the boot debugger with the regular operating system, unlike in the case of the hard to find ntldr_dbg for XP, only for it to be completely useless… Anyone using the boot debugger for purposes other than boot load driver replacement is probably working for Microsoft, so why should the boot debugger be a part of the OS if it is now missing what seems to be its most important functionality?
Hopefully the boot load driver replacement map will make a comeback in the Windows 7 boot debugger…
]]></content:encoded>
<wfw:commentRss>https://kobyk.wordpress.com/2008/07/04/replacing-boot-load-drivers-with-the-windows-boot-debugger/feed/</wfw:commentRss>
<slash:comments>5</slash:comments>
<media:content url="https://1.gravatar.com/avatar/1d5c3d0abc3891afb6e88eebc51b004c3ed48b5fc2bc4a0f0ff7f6e507c80ed4?s=96&d=identicon&r=G" medium="image">
<media:title type="html">KK</media:title>
</media:content>
</item>
</channel>
</rss>

Home · About · News · Docs · Terms