Microsoft Sync Framework

Microsoft Sync Framework is a comprehensive synchronization platform that enables collaboration and offline access for applications, services, and devices with support for any data type, any data store, any transfer protocol, and any network topology. Developers can build synchronization ecosystems that integrate any application, any data from any store using any protocol over any network. Sync Framework features technologies and tools that enable roaming, sharing, and taking data offline.

A number of providers are included by Sync Framework that support many common data sources. Although they are not required, to minimize development it is recommended that developers use these providers wherever possible. The following are the providers included:
  • Database synchronization providers: Synchronization for ADO.NET-enabled data sources
  • File synchronization provider: Synchronization for files and folders
  • Web synchronization components: Synchronization for FeedSync feeds such as RSS and ATOM feeds
Database Synchronization Providers:
The Sync Framework database synchronization providers were built to allow developers who were familiar with the concepts of ADO.NET to apply that knowledge to data synchronization through a very similar set of APIs to that of ADO.NET. The database synchronization providers offer the flexibility of a programming model like offline datasets and a richer synchronization feature set like that found in Merge replication. These providers also support synchronization over services, such as Windows Communication Foundation (WCF). Specifically, Sync Framework targets the following scenarios:

Offline Database Synchronization:
With Sync Framework you are able to build a solution where multiple remote clients connect and synchronize to a central ADO.NET database in a Hub-and-Spoke configuration. This enables occasionally connected devices to periodically connect and synchronize changes with a central ADO.NET database server. This topology is a common solution for remote workers such as sales reps or field service workers.

Collaboration Between Databases:
Sync Framework also includes Peer-to-Peer capabilities. Through a custom Peer provider, collaboration between two or more SQL Server databases can occur. Unlike a Hub-and-Spoke architecture, this provider enables a SQL Server database to communicate and exchange information with any other SQL Server database. This type of scenario is useful in group scenarios where users (such as auditors) need to update information and then collaborate those changes with other group members.

Synchronizing Files:
Sync Framework has a built-in algorithm for detecting changes that are made to the files and folders in the synchronization scope :

A change is reported when any of the following properties has changed:

  • The last modification time on a file.

  • If hashing is enabled, the value of the hash that was computed for the file.

  • The file size.

  • The file or folder name. This check is case-sensitive.

  • Any of the file attributes that are handled by the provider.

A file move or rename is reported when a file is found that has the same creation time, size, and hash value (when hashing is being used) as a previously known file, but the file has a different name or path. If more than one file is found that meets these criteria, Sync Framework acts as if the original file was deleted and new files were created.

Sync Framework treats a folder move or rename as if the old folder was deleted and the new folder was created. The files in the folder are reported as moves. Therefore, in this case, file data does not usually have to be re-sent.

ref:

Microsoft Sync Framework Overview - http://msdn.microsoft.com/en-us/sync/bb736753

Microsoft Sync Framework Beginner's Guide - http://msdn.microsoft.com/en-us/data/ff629461

Sync Framework Sample code(part of Microsoft SDK) - http://msdn.microsoft.com/en-us/library/bb902852.aspx



Introduction to Sync Framework Database Synchronization - http://msdn.microsoft.com/en-us/data/bb887608

How to Choose a Data Synchronization Technology: Offline & Collaboration - http://msdn.microsoft.com/en-us/data/cc470041

Microsoft Sync Team Tweets - http://twitter.com/syncfx

Microsoft Sync Team Blog - http://blogs.msdn.com/b/sync/

Getting Started with Microsoft Synchronization Services for ADO.NET(Developer.com) -

Take Data Offline Using Microsoft Synchronization Services for ADO.NET(CodeProject) - http://www.codeproject.com/KB/smart/takedataoffline.aspx

Detecting File Changes using Sync Framework - http://msdn.microsoft.com/en-us/library/bb902836.aspx


How to: Synchronize Files by Using Unmanaged Code(C++) - http://msdn.microsoft.com/en-us/library/cc305401.aspx

Sync Framework v4 is now Open Source, and ready to Connect any Device to SQL Server and SQL Azure - http://robtiffany.com/sync-framework/sync-framework-v4-is-now-open-source-and-ready-to-connect-any-device-to-sql-server-and-sql-azure


Microsoft Sync Framework 2.0 Software Development Kit (SDK) - http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=14159

Microsoft Sync Framework 2.1 Software Development Kit (SDK) - http://www.microsoft.com/download/en/details.aspx?id=23217

SOLID Object Oriented Design

SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Robert C. Martin which stands for five basic patterns of object-oriented programming and design in Agile Software Development.


SOLID -


SRP - Single Responsibility Principle (A class should have one, and only one, reason to change)


OCP - Open Closed Principle (open for extension, but closed for modification)


LSP - Liskov Substitution Principle (Derived classes must be substitutable for their base classes. if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program)


ISP - Interface Segregation Principle (Make fine grained interfaces that are client specific. clients should not be forced to implement interfaces they don't use)


DIP - Dependency Inversion Principle (Depend on abstractions, not on concretions. High-level modules should not depend on low-level modules. Both should depend on abstractions.)


ref:


http://en.wikipedia.org/wiki/Solid_(object-oriented_design)


http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod


http://www.c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign


Non-Software Design Patterns - http://cns2.uni.edu/~wallingf/teaching/062/sessions/support/pattern-examples.pdf


Interface Segregation Principle - http://www.objectmentor.com/resources/articles/isp.pdf


Pablo's SOLID Software Development - http://cdn.cloudfiles.mosso.com/c82752/pablos_solid_ebook.pdf


Visitor Pattern - http://ootips.org/visitor-pattern.html


Houston Design Patterns (Visitor) - http://www.vincehuston.org/dp/VisitorDemosCpp


http://www.lostechies.com/blogs/chad_myers/archive/2008/03/11/ptom-the-liskov-substitution-principle.asp

VMware Virtual Machine(VM) Remote Debugging using WinDBG

Instructions to setup WinDBG to debug VM in Kernel mode(on Windows XP):

Step 1: Edit the settings of you virtual machine to use a named pipe for a COM port

Edit
Settings
COM1
Named pipe:
Add: \\.\pipe\vpcdebug

Step 2: Edit boot.ini file on the virtual machine.

Right-click on My Computer
Properties
Settings
Edit start-up file manually:

Add: /DEBUG /DEBUGPORT = COM1 /BAUDRATE=115200
I like to add a second line here instead. Copy the last line, and append it with the above line:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect
/DEBUG /DEBUGPORT=COM1 /BAUDRATE=115200

This will give you two different boot options, one for debugging and the other for normal use.

Step 3: Set up WinDbg for remote debugging over COM1.
This can be done through the File -> Kernel Debug menu, but I prefer to make a shortcut so I can have multiple different types of debugging environments.

Create a shortcut that points to WinDbg.exe and add the the necessary command-line arguments. Your shortcut target should look something like this:
"C:\Program Files\Debugging Tools for Windows\windbg.exe" -k com:pipe,port=\\.\pipe\vpcdebug,resets=10

This is all you need to do to set up kernel debugging. Be sure to start the VM before WinDbg so that it has a chance to create the named pipe. Also, make sure you download the correct symbols for your environment. For example:

SRV*c:\websymbols* http://msdl.microsoft.com/download/symbols

Instructions to setup WinDBG to debug VM in Kernel mode(on Vista and above):

debug kernel

/debug /debugport=com1 /baudrate=115200

for Vista

bcdedit

bcdedit /copy {current} /d "DebugBoot"

(note new guid)

bcdedit /displayorder {current} {guid}

bcdedit /debug {guid} ON


On the "debugging server" (the PC with the problem)

Start WinDBG
Type .server npipe:pipe=pipename

On the "debugging client" (the one you're sitting at)

Start WinDBG
Go to File>Connect to Remote Session
For Connection String enter npipe:server=Server, pipe=PipeName [,password=Password] where Server is the hostname/IP and PipeName is the name that the server chose. The password section is optional.

Miscellaneous:

Use “CONTROL+BREAK” command if “Debuggie is not connected” is shown …

If the VM looks like HANG/LOCKED after starting Kernel debugging then type “g” in the WinDbg commandline so that debugging starts and we get the VM unlocked J

ref:


WinDbg remote debugging and Vmware - http://silverstr.ufies.org/lotr0/windbg-vmware.html


Bitwise Operators

Bitwise OR => to "set" or "turn on" a "flag"
Bitwise AND => used to check the state(0/1) of a flag in your flags variable
Bitwise XOR => used to toggle the flag bits of a MASK in your flags variable
Bitwise NOT => used to toggle the bits
Left Shift => Multiply 2
Right Shift => Divide by 2

ref:

C# .Net Books


CLR via C# by Jeffrey Richter(3rd edition adds a lot of useful info on threading and the new parallel extensions)

Professional .NET 2.0 Framework by Joe Duffy is very similar to Richters book, so I like it for the same reasons

C# in Depth by Jon Skeet is an excellent treatment of all the stuff that the two others do not cover

Programming C# By Jesse Liberty

C# Cookbook By Jay Hilyard and Stephen Teilhet

Applied Microsoft .NET Framework Programming - Jeffrey Richter

Essential C# 4.0 by Mark Michaelis

C# 4.0 in a Nutshell. Excellent reference

Effective C# - Best Practices

More Effective C# - Best Practices

The C# Programming Language by Anders Hejlsberg

Programming .Net components by Juval Lowy

Pro ASP.NET 2.0 in C# 2005

The C# language specification (get the book for the annotations)

VMware vShield EndPoint Security: Agentless VM Security Solution

Strengthen security for virtual machines and their hosts while improving performance by orders of magnitude for endpoint protection, with VMware vShield Endpoint, part of the VMware vShield family. Offload antivirus and anti-malware processing to dedicated security-hardened virtual machines delivered by VMware partners. Leverage existing investments and manage antivirus and anti-malware policies for virtualized environments with the same management interfaces as physical environments.

VMware vShield Endpoint comprises a hardened, security virtual machine that hosts the third-party anti-virus software. Each virtual machine requiring AV protection only requires a small-footprint, driver software, deployed as a loadable kernel module per vSphere host.

How Does VMware vShield Endpoint Work ?

vShield Endpoint protects virtual machines and their hosts against viruses, malware and other threats. vShield Endpoint plugs directly into vSphere and consists of three components:

1. Hardened security virtual machine (delivered by VMware partners)

2. Driver for virtual machines to offload file events

3. VMware Endpoint Security (EPSEC) loadable kernel module (LKM) to link the first two components at the hypervisor layer

Partner Integrations :

Integration of VMware vShield Endpoint with security virtual machine solutions from VMware partners is facilitated through VMware EPSEC, which provides a library and API for introspection into file activity at the hypervisor layer. vShield Endpoint monitors virtual machine file events and notifies the antivirus engine, via VMware EPSEC, which scans and returns a disposition. It also supports scheduled full and partial file scans initiated by the antivirus engine in the security virtual machine.

ref



Understanding VMware vShield Endpoint And Agentless Malware Protection -


Trend Micro integration with VMware endpoint security - http://www.vmwareforum2011.com/library/documents/finland_1100_trendmicro_session.pdf

Windows Services Enhancements in Vista and above - Automatic Delayed Start & NotifyServiceStatusChange() API

Auto-start services to be started only after Windows has finished its own startup process. Specifically, a delayed auto-start service is activated roughly two minutes after regular auto-start services. The Service Control Manager (SCM) also creates the main service thread with a lower priority, ensuring that any logged on user isn't notably impacted by delayed auto-start services. The priority is set back to normal after the service updates its state indicating that it is running. You can force a delayed auto-start service to start sooner by using the StartService function if it turns out that it hasn't started by the time your application needs to make use of it.

Example: Windows Security Center Service(wscsvc) starts a Automatic delayed start Service.

Sample Code:
bool ChangeDelayedAutoStart( SC_HANDLE service, bool delayed)
{

ASSERT(0 != service);

SERVICE_DELAYED_AUTO_START_INFO info = { delayed };

return 0 != ::ChangeServiceConfig2(

service,

SERVICE_CONFIG_DELAYED_AUTO_START_INFO,

&info);

}


Service State Change Notifications

Earlier than Windows Vista, the only way for a client to determine whether a service had changed its status or been created or deleted was to use the service query API—such as the QueryServiceStatusEx function—and poll the status of the service. This was not the best approach because these polling loops reduced system performance. In addition, polling loops have historically been a significant source of bugs.

Windows Vista introduces a new function, NotifyServiceStatusChange, which allows the SCM to notify a client when a specified service is created, is deleted, or changes its status.

How to Have a Client Notified When a Service's State Changes:

To register for state change notifications, a client calls NotifyServiceStatusChange to specify the service and change that they want to be notified of. They also provide the SCM with a pointer to a callback function. When the specified change takes place, the SCM calls the callback function to notify the caller.

The following list contains several notes on the use of NotifyServiceStatusChange. For more information, see the function's reference page, which is listed in "Resources" at the end of this paper.

· NotifyServiceStatusChange can be used by local or remote clients.

· The callback function is called only once. If the client wants a subsequent notification for this change, the client must call NotifyServiceStatusChange again and reregister the callback function.

· The callback function is normally called after a transition to the specified state has occurred. There is an exception to this rule for the first time that the caller invokes NotifyServiceStatusChange. In that case, if the service is already in the specified state, SCM calls the callback function.

· Clients can cancel the notification by calling CloseServiceHandle to close the service handle.

· Clients should not exit the thread that they used to call NotifyServiceStatusChange unless the callback function has been called or they have canceled the notification. Otherwise, they will create a memory leak.

· If one or more services hold open handles to a service, the service is not deleted until the next time the system is booted. If this is the case, no delete notification is sent.

Note: A caller must have the SERVICE_QUERY_STATUS access right to call NotifyServiceStatusChange. By default, only administrators, power users, and server operators on a domain controller can get this right remotely. Services and interactive users can get this right locally.


ref:

Windows Services Advanced concepts - http://msdn.microsoft.com/en-us/magazine/cc164252.aspx

Windows Services in Windows Vista(Service State Change Notifications) - http://www.scritube.com/limba/engleza/software/Services-in-Windows-Vista1731861210.php

VC++ sample code(using NotifyServiceStatusChange) - http://www.experts-exchange.com/Programming/Languages/CPP/Q_23586927.html

NTFS Links: Hard Links, Junctions, Symbolic Links

There are three types of file links supported in the NTFS file system:

  1. hard links
  2. junctions
  3. symbolic links.


Hard Links

A hard link is the file system representation of a file by which more than one path references a single file in the same volume. A hard link directly points to the file, and acts to the operating system as if it is the file itself. You’ll want to use this option the majority of the time if you are trying to fake an application’s directory.


NTFS Junctions (or) Soft Links

A soft link on filesystems is not a link to a file itself, but to a file name; this also creates aliasing, but in a different way. A soft link is essentially a shortcut to a file or folder – if you are using Windows explorer, you’ll be redirected to the directory if you double-click on a shortcut, it won’t pretend its part of the filesystem. You can still directly reference or open a file with the symlinked path, and it mostly works.

A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer. Otherwise, junctions operate identically to hard links. Junctions are implemented through reparse points.

An NTFS junction point is a feature of the NTFS file system that provides the ability to create a symbolic link to a directory which then functions as an alias of that directory. This has many benefits over a Windows shell shortcut (.lnk) file, such as allowing access to files within the directory via Windows Explorer, the Command Prompt, etc.


Symbolic Link

A NTFS symbolic link (symlink) is a filesystem object in the NTFS filesystem that points to another filesystem object. The object being pointed to is called the target. Symbolic links should be transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with POSIX operating systems, and were introduced with the modifications made to the NTFS file system with Windows Vista.

Unlike an NTFS junction point (available since Windows 2000), a symbolic link can also point to a file or remote SMB network path. While NTFS junction points support only absolute paths on local drives, the NTFS symbolic links allow linking using relative paths. Additionally, the NTFS symbolic link implementation provides full support for cross-filesystem links. However, the functionality enabling cross-host symbolic links requires that the remote system also support them, which effectively limits their support to Windows Vista and later Windows operating systems.

In Unix Terminology,

Hard Link => 2 different files pointing to the same Inode. Parent & Child can exist on their own. Delete Parent but child can still survive.

Symbolic Link => 2 different files pointing to 2 different Inodes. Child refers to the parent path. Deleting the Parent has cascading effect(by deleting the Child too) !

File System Filter Drivers vs Device Drivers

The following subsections describe some of the differences between file system filter drivers and device drivers.

No Power Management

Because file system filter drivers are not device drivers and thus do not control hardware devices directly, they do not receive IRP_MJ_POWER requests. Instead, power IRPs are sent directly to the storage device stack. In rare circumstances, however, file system filter drivers might interfere with power management. For this reason, file system filter drivers should not register dispatch routines for IRP_MJ_POWER in theDriverEntry routine, and they should not call PoXxx routines.

No WDM

File system filter drivers cannot be Windows Driver Model (WDM) drivers. The Microsoft Windows Driver Model is only for device drivers. For more information about file system driver development in Windows Me, Windows 98, and Windows 95, see the Windows Me Driver Development Kit (DDK).

No AddDevice or StartIo

Because file system filter drivers are not device drivers and thus do not control hardware devices directly, they should not have AddDevice or StartIo routines.

Different Device Objects Created

Although file system filter drivers and device drivers both create device objects, they differ in the number and kinds of device objects that they create.

Device drivers create physical and functional device objects to represent devices. The Plug and Play (PnP) Manager builds and maintains a global device tree that contains all device objects that are created by device drivers. The device objects that file system filter drivers create are not contained in this device tree.

File system filter drivers do not create physical or functional device objects. Instead, they create control device objects and filter device objects. The control device object represents the filter driver to the system and to user-mode applications. The filter device object performs the actual work of filtering a specific file system or volume. A file system filter driver normally creates one control device object and one or more filter device objects.

Other Differences

Because file system filter drivers are not device drivers, they do not perform direct memory access (DMA).

Unlike device filter drivers, which can attach above or below a target device's function driver, file system filter drivers can attach only above a target file system driver. Thus, in device-driver terms, a file system filter driver can be only an upper filter, never a lower filter.

ref:

http://msdn.microsoft.com/en-us/library/ff548075(v=vs.85).aspx

Sample Filter Driver code -

http://read.pudn.com/downloads2/sourcecode/windows/system/4397/WinntInternalFS/filesys/src/sfsdinit.c__.htm




Full Virtualization vs Para Virtualization

There are several ways to implement virtualization. Two leading approaches are full virtualization and para-virtualization.

Full virtualization is designed to provide total abstraction of the underlying physical system and creates a complete virtual system in which the guest operating systems can execute. No modification is required in the guest OS or application; the guest OS or application is not aware of the virtualized environment so they have the capability to execute on the VM just as they would on a physical system. This approach can be advantageous because it enables complete decoupling of the software from the hardware. As a result, full virtualization can streamline the migration of applications and workloads between different physical systems. Full virtualization also helps provide complete isolation of different applications, which helps make this approach highly secure. Microsoft® Virtual Server and VMware® ESX Server™ software are examples of full virtualization.

Para-virtualization presents each VM with an abstraction of the hardware that is similar but not identical to the underlying physical hardware. Para-virtualization techniques require modifications to the guest operating systems that are running on the VMs. As a result, the guest operating systems are aware that they are executing on a VM—allowing for near-native performance. Para-virtualization methods are still being developed and thus have limitations, including several insecurities such as the guest OS cache data, unauthenticated connections, and so forth. Xen is an open source virtualization software based on paravirtualization technology.

Xen 3.0 Aerchitecture: The Intel x86 architecture provides four levels of privilege modes. These modes, or rings, are numbered 0 to 3, with 0 being the most privileged. In a non-virtualized system, the OS executes at ring 0 and the applications at ring 3. Rings 1 and 2 are typically not used. In Xen para-virtualization, the VMM executes at ring 0, the guest OS at ring 1, and the applications at ring 3. This approach helps to ensure that the VMM possesses the highest privilege, while the guest OS executes in a higher privileged mode than the applications and is isolated from the applications. Privileged instructions issued by the guest OS are verified and executed by the VMM.

Compare Vmware Esx, Microsoft Hyper-V & Citrix Xen - http://www.vmware.com/technical-resources/advantages/robust-foundation.html

Misc -

Windows Minifilter Driver - User mode to Kernel mode Communication


The filter manager supports communication between user mode and kernel mode through "communication ports". The minifilter driver controls security on the port by specifying a security descriptor to be applied to the communication port object. Communication through a communication port is not buffered, so it is faster and more efficient. A user-mode application or service can reply to messages from a minifilter driver for bidirectional communication.

ref:

User mode to Kernel mode communication (Communication Ports) - http://msdn.microsoft.com/en-us/library/ff539277(v=vs.85).aspx

User-Mode Interactions: Guidelines for Kernel-Mode Drivers(KM-UMGuide.doc) -

User to Kernel Communication Model - http://muglin.ru/messagesupport.ppt

Filter Manager support in Usermode - http://muglin.ru/UserModeLib.ppt

Windows FileSystem Mini Filter Driver Development



A File system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of file system filter drivers include anti-virus filters, backup agents, and encryption products. To develop file systems and file system filter drivers, use the IFS (Installable File System) Kit, which is provided with the Windows Driver Kit (WDK).
Filter Manager and Minifilters Basics:

The Filter Manager is a file system filter driver provided by Microsoft that simplifies the development of third-party filter drivers and solves many of the problems with the existing legacy filter driver model, such as the ability to control load order through an assigned altitude. A filter driver developed to the Filter Manager model is called a minifilter. Every minifilter driver has an assigned altitude, which is a unique identifier that determines where the minifilter is loaded.
A minifilter driver can be loaded at any time while the system is running. If a minifilter driver's INF file specifies a driver start type of SERVICE_BOOT_START, SERVICE_SYSTEM_START, or SERVICE_AUTO_START, the minifilter driver is loaded according to existing load order group definitions for file system filter drivers, to support interoperability with legacy filter drivers. While the system is running, a minifilter driver can be loaded through a service start request (sc start, net start, or the service APIs), or through an explicit load request (fltmc load, FltLoadFilter, orFilterLoad).

A minifilter driver's DriverEntry routine is called when the minifilter driver is loaded, so the minifilter driver can perform initialization that will apply to all instances of the minifilter driver. Within its DriverEntry routine, the minifilter driver calls FltRegisterFilter to register callback routines with the filter manager and FltStartFiltering to notify the filter manager that the minifilter driver is ready to start attaching to volumes and filtering I/O requests.

Minifilter driver instances are defined in the INF file used to install the minifilter driver. A minifilter driver's INF file must define a default instance, and it can define additional instances. These definitions apply across all volumes. Each instance definition includes the instance name, its altitude, and flags that indicate whether the instance can be attached automatically, manually, or both. The default instance is used to order minifilter drivers so that the filter manager calls the minifilter driver's mount and instance setup callback routines in the correct order. The default instance is also used with explicit attachment requests when the caller doesn't specify an instance name.

Excerpts:
1. CreateService() API loads FilterDriver …. It’s equivalent of FilterLoad() API
2. StartService() API calls DriverEntry() API
3. StopService() API calls the DriverUnloadCallback() registered with FltRegisterFilter() API … This is not a real DriverUnload ; it’s kind of stopping the driver to work !
4. DeleteService() API calls the FilterUnload() API & which really unloads the driver.
i.e
FilterLoad() => CreateService() + StartService()
FilterUnload() => DeleteService()
StartService() => DriverEntry()

ref:

An Introduction To Writing TDI Filter Drivers - http://www.iseclab.org/papers/Writing_TDI_Drivers.pdf

Sample TDI Driver Firewall Opensource code - http://sourceforge.net/projects/tdifw/




Developing FileSystem Mini filter drivers - http://www.osr.com/filters.pdf

Filter Driver Development Kit - http://www.osr.com/fddk.html

Writing a FileSystem Filter Driver (VC++ sample code) - http://www.codeproject.com/KB/system/fs-filter-driver-tutorial.aspx?msg=3369734&display=Mobile
Loading & Unloading TDI Device drivers - http://www.codeproject.com/KB/system/tdriver.aspx
FileSystem Mini Filter driver (which makes use of IFS kit) - http://www.microsoft.com/whdc/DevTools/IFSKit/IFSKit_About.mspx
IFSK sample code - http://msdn.microsoft.com/en-us/library/ff548099(v=VS.85).aspx
Filter Driver - http://www.microsoft.com/whdc/driver/filterdrv/default.mspx
Handling file Rename - http://read.pudn.com/downloads126/ebook/535717/OSR_docs/Rename.pdf
IRP_MJ_SET_INFORMATION irp - http://ddk.h16.ru/index.php?BID=4&PID=490
File Screening Minifilter Driver - http://technet.microsoft.com/en-us/library/dd364850(WS.10).aspx
I/O System Filter Driver - http://www.calsoftlabs.com/whitepapers/filter-driver.html
File System Filter Driver Tutorial(CodeProject) - http://www.codeproject.com/KB/system/fs-filter-driver-tutorial.asp
Usermode to Kernel mode communication (Communication Ports) - http://msdn.microsoft.com/en-us/library/ff539277(v=vs.85).aspx
Kernel Sockets(TDI Driver) - http://msdn.microsoft.com/en-us/library/ff565094(v=vs.85).aspx

Windows Driver Kit Sample code - http://msdn.microsoft.com/en-us/library/ff554118(v=VS.85).aspx
Windows Driver Kit - http://msdn.microsoft.com/en-us/library/ff557573(v=VS.85).aspx