Best Practices Microsoft

Where are Device Drivers stored in Windows 7? – DriverStore

DriverStore is a new and a central location in Windows where all the driver files will be stored., before they are copied to their final destination during the device driver installation. The location of the driver store is – C:\Windows\System32\DriverStore

Driver files are stored in folders, which are located inside the FileRepository folder as shown in the image below.

Driver Store

Here is a screenshot from the latest version of Windows 10.


For eg: the driver package developed by Microsoft that contains the core mouse support files is present in the following folder.


Within this folder are the driver files (.sys), driver setup files (.inf), pre-compiled INF files(.pnf), and an XML manifest file that contains the manifest of all the files within the driver package. Together, all of these different files add up to the driver package, which contains all the files needed to install the device. To protect these files, the NTFS permissions on the driver store and its sub-folders and files is full control for the local system account and Read& Execute for the Everyone built in identity.

Earlier in Windows XP and 2000, the driver source files neeeded for installing the devices were typically found in several locations.

  • %SystemRoot%\Driver Cache\i386\
  • %SystemRoot%\Driver Cache\i386\
  • .inf files under %windir%inf
  • .sys files under %SystemRoot%\System32\Drivers
  • Support DLLs under %SystemRoot%\System32
  • Third Party co-installers in various locations.

Advantages of maintaining a central store:

  1. Allows for potentially faster device installation and more realiable driver rollback and is a single standard for un-installing drivers.
  2. Allows you to protect drivers by using the Windows Resource Protection(WRP).
  3. Uses index files to minimize the performance impact on installing devices when the driver store grows in size as a result of new package additions.

To learn, How to get an Inventory of all the Installed Device Drivers in a Machine – Read this article

References: Vista Resource kit and Technet

Microsoft Windows Installer, Application Compatibility and Deployments

How do I Solve Compatibility Issues use AppCompat Flags?

Just a small info on Application Compatibility.., Flag registry keys does solve the app launch UAC problems on Vista/ Windows 7.

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
“C:\Program Files\ABC\law.exe”=”RUNASADMIN”

In this hive, give in the exe name, along with the runas key. This will solve much of our problem. Also the document attached should be of real help to you.

Windows Vista UAC Development Requirements

PS: This is purely a Developer/Packager solution.

General Microsoft

Mis-understood Features of Windows Vista

This is a very good article to understand Windows Vista better. There are lot more to talk about. Once you go through that article, I believe your complains would be reduced for sure !!!!

You can obtain the article from here

Microsoft Windows Installer, Application Compatibility and Deployments

APPCRASH Messages – Overview and Example Scenarios

Vista and Windows 7 have a variety of fault-protection systems that try to prevent a crashing application from taking down your entire computer. When Windows Vista detects that an application has crashed, it terminates it and generates an Appcrash error report. This report is useful, since it can be sent to Microsoft Team. Most of the applications crashes give an exception code of c0000005.

APPCRASH Scenarios: (in the order of their occurrence Rates)

Scenario 1
Problem Event Name: APPCRASH
Application Name: explorer.exe
Application Version: 6.0.6001.18000
Application Timestamp: 47918e5d
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.6001.18000
Fault Module Timestamp: 4791a727
Exception Code: c0000005
Exception Offset: 00009c00
OS Version: 6.0.6001.
Locale ID: 1041
Additional Information 1: 72b2
Additional Information 2: 693d7799b8b778ed847472df9568cf8f
Additional Information 3: a1b0
Additional Information 4: 0d44ab9553a107ee7d95071a61aa480b

This problem can be solved, if the dll or supported depreciated dll is isolated to the application installation directory. For eg: Renaming cmoctl32.dll file to .old and let it rebuild itself. Like trashing an ini file and letting it rebuild itself.

Scenario 2
When some core application components (VB and VC++ runtime, DHTML controls etc…) are missing the machine/build, we get the APPCRASH message for few of the applications.

Scenario 3
Problem Event Name: APPCRASH
Application Name: PhotoStudio.exe
Application Version:
Application Timestamp: 46861e12
Fault Module Name: dtype32.dll
Fault Module Version:
Fault Module Timestamp: 3ebed48a
Exception Code: c0000005
Exception Offset: 0000e004
OS Version: 6.0.6001.
Locale ID: 2057
Additional Information 1: d6bf
Additional Information 2: 0623d5f43aa286e60fe956167dbc9d6f
Additional Information 3: f083
Additional Information 4: 4aaeb79ec497d908d232129b547584f0

In these scenarios the application is not supported to run in Vista. Here we need the latest version/update to work with Vista. For the entire list of applications which works on Vista, refer to this link.

Applications which work with Vista

VISTA Certified applications List

Scenario 4
Sometimes, on invoking the application shortcuts, we get the appcrash message with CLR20r3 error. This error occurs when there is a un-compatible .NET framework installed. It’s an exception in Winforms that Under References, System, System.Data, System.Drawing, System.Windows.Forms, and System.XML might have been developed references to .NET framework 1.1.

In few scenarios, the application doesn’t work if a higher version of framework is installed. In this case, we may need to create a manifest where we inform the application to check only for the framework 2 or 1.1 components.

Scenario 5
Some Application services which is not compatible to start with Vista, throws the APPCRASH message.
An exception here is that, services which are running in session 0 will show a Session 0 Isolated OTS window.

Scenario 6
When you have a third party control panel applet (older version of application), we have an appcrash pointing to explorer.exe.
In this case, we will need to update the application with the newer version.

Scenario 7
Seemingly random crashes are often caused by RAM errors. This can happen in Vista and not XP because of the way Vista loads. Vista uses something called Address Space Load Randomization (ASLR) to load the system into slightly different areas of RAM every time it loads as a security feature. XP doesn’t do this. This means if you have bad RAM (or bad hardware causing the symptom of bad RAM) XP may not notice it because the bad RAM isn’t in a system area. Vista because it loads the system into varying areas of RAM may crash with many different errors.

One Solution for this is to run SFC (System File Checker

If you find/or have encountered few other scenarios, please add your comments to this page.

How-to Windows Installer, Application Compatibility and Deployments

How to Test Application MSI Packages for UAC

The easiest way to simulate the UAC is to install an MSI from an elevated command line. In Vista choose to run the command prompt as Administrator. Then install an MSI. You can flag an MSI, by modifying the WordCount in the Summary Information Stream, so that it does not automatically require elevation during an install. This MSI would only be able to write to the user profile and not any protected system location. In corporate deployments this is a rare scenario.

The application installer will always need to be elevated but this will be handled by the deployment tool. If an application does turn out to be badly written then this scenario can be handled in the same way as under a locked down XP machine. Specific NTFS permissions would be given for the file, folder or registry key.

Best Practices Microsoft

Windows 7 – File and Registry Redirection : Impact on MSI Packaging

The basics of this feature is explained in the article Folder Virtualization Concepts in Windows Vista.

Impact in MSI Packaging
Files in a registry key can be found twice in your installation. Especially if the application has to be launched to customize options and settings.

Possible Work-around
During Setup-Capture:

Virtualized resources needs to be merged with the original files and the virtualized resources can be deleted from the installation resources. If file and registry virtualization is enabled on the default user environment, you will need to test the application with two different default user accounts. Check if resources from the application gets virtualized and that those contents will not affect the proper functionality of the application.

The best practice is to disable the file and registry virtualization. Microsoft does not guarantee this feature will be in future releases of Windows. If a file or registry key needs permission changes, use the LockPermission table or use a custom action to modify the related security descriptor of those resources. If the user has the permission to modify the resources, it won’t be virtualized.

It’s recommended to use the latest release of a product that supports Vista. Applications following the Microsoft development guidelines for Vista compliant applications, are modifying resources in the user profile where virtualization will not take place.