What are the drivers called? What is the name of the motherboard driver?

All tips

We invited everyone to participate in voluntary assistance in the development of the next versions of DRP, today it’s time to talk about how exactly we create an important thing when working with large archives of drivers (necessary for system administrators and other professionals involved in “serial” configuration of computers) - indexes.

For each user, an index of all drivers present in the system, including the operating system itself, is collected on the local computer. Its presence allows you to speed up the search for drivers for installed devices, and in the future – for updating them. In other words, we cannot live without an index; its creation and further updates have a critical impact on the speed and efficiency of our application.

Silicon Valley heroes are working on optimizing their own algorithms

How to build a custom driver index

Each device in the system has its own unique number ( DevID).
It appears in both Windows installations and the DriverPack Solution program. An identifier unique for each device (unambiguously characterizing each device) is used by the program to automatically “select” a driver for it.

The database in the program contains the IDs of all devices, independently tracks driver versions for them, compares their versions and relevance. If there is a newer version in the database, the program automatically suggests installing a new driver for the device. You can find a driver for a specific device yourself on the Internet by selecting the appropriate driver search mode.

For the program to work effectively, driver archives are required (in the format " 7z"), and to quickly search through them, you need to index the files contained inside.

In addition to the (quite extensive) driver archives already contained in the program, DriverPack Solution provides the ability to create custom driver packs. This is true both in the presence of non-standard equipment and in the “attachment” of the user’s operating system to certain types of (possibly outdated) drivers.

New drivers, after unzipping them, are “scattered” across folders that contain a lot of files that, at first glance, are completely “unnecessary” for the user.

In order to select the “necessary” files, you need to find one with the *.inf extension in the unpacked files.
It is he who contains (in the section ) a list of required files, according to which you need to copy the list of files to a folder previously created by the user.

Note: if there is no .inf file among the unpacked files, then automatic creation of a driver package is impossible. It is strongly recommended not to delete files with the extension *.SAT– information about the digital signature.

As it was before

Until 2010, when there were slightly fewer versions of Windows, we used the following method for creating an index for the driver assembly.

A folder D (short for “Drivers”) is created, and the drivers are placed in any subfolder inside the D directory.
The name of the subfolder (subdirectory) can be anything, but it is recommended to use the shortest names possible. You should avoid long paths to files - this can lead to errors and prevent installation.

When creating your driver package folder structure, you should follow certain common naming conventions. Only English folder names must be used.

In the created folders, drivers are divided by manufacturer, thereby forming subfolders.
Manufacturer names are also recommended to be abbreviated as much as possible. For example: “NVidia” - “N”, “ATi” - “A”, etc. Inside the folder with the manufacturer’s name, the drivers are located in folders 1-9; if necessary, the number of folders can be increased. After creating the required folder structure, place your drivers in the appropriate subfolders (note: unzipped files, .inf files, not archives or installers).

Folder name	English name	Explanation
A	Additions	Add-ons
B	Broadband	Broadband network devices (*DSL modems and the like)
C	Chipset	System logic sets (chipsets)
CPU	Central processor unit	CPU (required for AMD K8)
D	Dial-Up	Modems
G	Graphics	Video adapters (Graphics cards)
L	LAN	Network adapters
M	Mass Storage	Hard drive controllers
P	Printers	Printers
S	Sound	Sound adapters
VMWare	VMWare	Drivers for VMWare virtual machine
W	WLAN	Wireless adapters
U	USB	USB devices (flash drives, cameras)
Y	Misc	Miscellaneous (Everything that is not included in other sections)
Y	Monitor	Monitors
Z	Hid	Input devices (Smart mice, keyboards, touchpads, etc.)

Process for creating (custom) driver packages

After creating a folder structure with new drivers, you need to archive the created folder (in the example, this is the “D” folder) in accordance with the program’s archive requirements.

Archive name: "DP_Name of Driver Package_ x86-32_Version of Driver Package.7z"
Requirements: archive name must not contain spaces. For example, the name of the driver package version 9.06 for hard disk controllers should be: “DP_MassStorage_x86-32_906.7z.”
Archive format: 7z
Compression level: "Ultra"(to ensure maximum compression, you can specify a lower compression level if desired).
Compression method: "LZMA"(the value is set by default, it is not recommended to change it).
Dictionary size: 32 Mb

Word size: 256.

The latter is installed by default. You can increase or decrease the value of this parameter. Increasing this parameter allows you to achieve greater compression, but requires more time to create an archive.

Index files are stored in *.txt- format, and are located in the folder "Indexes" and not in "dev_db", as it was before.

It is advisable to consider the structure of index files using the example of two drivers.

Contents of the index file for the 1st:
– "PCI\VEN_8086&DEV_24D5&SUBSYS_680316F3 Audio_w7x64_912.2\ Audio_w7x64_912.2\3\1\Alcwdm18.inf Realtek.NTamd64 06/19/2009,6.0.1.6305 Realtek AC"97 Audio"

Contents of the index file for the 2nd:
– "HDAUDIO\FUNC_01&VEN_10DE&DEV_8067 Audio_w7x64_912.2\ Audio_w7x64_912.2\11\1\nvhda.inf VIDIA.NTamd64 11/11/2009,1.00.00.63 NVIDIA High Definition Audio"

A more detailed explanation of the structure is given in the table:

Current realities

Today there is no strict connection to the index structure; it is called “free style”.

The main thing is to use operating system markers. Additionally, there are markers for almost all laptop manufacturers.
In this case, the location and name of folders and subfolders ceased to matter; the only requirement is the presence of at least one system marker.

In fact, the marker is the specific name of the folder. It can be seen in the name of one of the subdirectories of the driver pack: DRP\Drivers\DP_Chipset_14101.7z\Intel\ WinAll\Chipset\9.4.0.1007_HECI\

In this case, “WinAll” means “all versions of Windows.”

Markers

Windows version = marker (subfolder name), characterizing that the driver located inside the marker folder is suitable for the specified OS.

XP x64 = "5x64";
XP x86 = "5x86";
Vista x64 = "6x64|NTx64|AllNT|67x64";
Vista x86 = "6x86|NTx86|AllNT|67x86";
Windows 7 x64 ="7x64|NTx64|AllNT|67x64|78x64|781x64|7819x64";
Windows 7 x86 = "7x86|NTx86|AllNT|67x86|78x86|781x86|7819x86";
Windows 8 x64 ="8x64|NTx64|AllNT|78x64|All8x64";
Windows 8 x86 = "8x86|NTx86|AllNT|78x86|All8x86";
Windows 8.1 x64 = "81x64|NTx64|AllNT|781x64|7819x86|All8x64";
Windows 8.1 x86 = "81x86|NTx86|AllNT|781x86|7819x86|All8x86";
Windows 9 x64 = "9x64|NTx64|AllNT|7819x64|All8x64|81x64";
Windows 9 x86 = "9x86|NTx86|AllNT|7819x86|All8x86|81x86";
Windows 10 x64 = "10x64|NTx64|AllNT|78110x64|All8x64";
Windows 10 x86 = "10x86|NTx86|AllNT|78110x86|All8x86";
All x64 = "Allx64";
All x86 = "Allx86";
All XP = "AllXP";
All Vista = "All6";
All Windows 7 = "All7";
All Windows 8 = "All8";
All Windows 8.1 = "All81";
All Windows 9 = "All9";
All Windows 10 = "All10";
Any Windows = "WinAll";

Laptop markers

Marker folder with the name of the laptop manufacturer = a word used by the manufacturer itself to identify its laptops

Acer_nb = acer / emachines / packard*bell / gateway / aspire
Apple_nb = apple
Asus_nb = asus
Dell_nb = dell/alienware/arima/jetway/gericom
Fujitsu_nb = fujitsu/siemens
Gigabyte_nb = gigabyte
HP_nb = hp/compaq
Lenovo_nb = lenovo/compal/ibm
LG_nb = lg
MSI_nb = msi/micro-star
NEC_nb = nec
Panasonic_nb = panasonic / matsushita
Samsung_nb = samsung
Sony_nb = sony/vaio
Toshiba_nb = toshiba
OEM_nb = other vendors (benq / clevo / depo / durabook / ecs / elitegroup / eurocom / getac / intel / iru / k-systems / medion / mitac / mtc / nokia / pegatron / prolink / quanta / sager / shuttle / twinhead / rover /roverbook/viewbook/viewsonic/vizio/wistron etc.)

Current index

If, when downloading updated driver packs from our website, their file names are the same (for example, the old and new files have the name "DP_Chipset_14112.7z"), you can simply replace old files with new ones.
If there is the same file, but with a lower number, you can delete it: downloaded "DP_Chipset_14112.7z", but in the folder there is "DP_Chipset_14111.7z"- file with a lower version number "DP_Chipset_14111.7z" can be deleted.

Indexing new driver packs (creating lists of supported devices).
If the old indexes are deleted, then when you start DRP, the program will automatically ask you to index new driver packs - for example, a program for a new driver pack "DP_Chipset_14112.7z" creates index files "DP_Chipset_14112_xxx.xxx" in the appropriate folder in "X:\DRP\Indexes\".

You can also delete old indexes.
In folder "Indexes" you need to remove all files from the old driver pack.
The index file name corresponds to the name of the driver pack and is easy to find. For example, you downloaded a driver pack "DP_Chipset_14112.7z" and you had "DP_Chipset_14111.7z", respectively, delete all index files "DP_Chipset_14111_xxx.xxx", if both the downloaded and the old driver-pack have the same name, for example "DP_Chipset_14112.7z", then the indices "DP_Chipset_14112_xxx.xxx" also needs to be removed because The list of supported devices in the new version of the driver pack may differ.

If you are too lazy to look for the index you need to delete, you can delete the entire folder "Indexes" and then the program will create indexes for all driver packs, and not just for the new one, which will take more time, but the result will be identical.

We hope that this guide to creating a driver index will be useful not only

17.02.2017

Probably everyone who has reinstalled an operating system has found themselves in an awkward situation when they need to install drivers for a video card, but its model is unknown. Or you just need to update the drivers on your video card without knowing its name. Usually in such situations they use the installation disk, which is necessarily sold with the video card. But what if for some reason such a disk is missing?

For stable operation of a video card, you need to not only install drivers for it, but also regularly update them when new versions appear. Moreover, the driver version sometimes affects the performance of the video card. Let's figure out how to find out the video card model and where to download the latest drivers for it.

Unfortunately, it is impossible to determine the video card model online. To determine, use special programs.

How to find out your video card model

There are several ways to find out exactly which video card you have installed.

Method 1: Find out the video card model using the hardware identifier

On the desktop icon "My computer" ("This computer" in Windows 10) right-click and select the item in the window that appears "Properties".

In the window that appears, find the line "Device Manager" and click on it.

Next you need to open the branch with the section "Video adapters". It will display the video cards connected to the computer. If the drivers have already been installed, you will see the full name and model of the video cards.

This may be sufficient if you just want to update already installed drivers. If there are no drivers at all, then most likely you will see the line in the list of video adapters "Standard VGA graphics adapter" or .

Right-click on such an unidentified video card and select the item from the drop-down menu "Properties".

In the list of bookmarks at the top we find "Intelligence" and go there.
Under the inscription "Property" you will see a drop-down menu that you need to click on. Looking for a string "Equipment ID".

In field "Values", which is located below, you will see several lines. You need to select the last one, right-click on it and select the item in the menu "Copy".

After the ID has been copied, go to the next site
Once you click on the link, you will see a search field at the top of the site. Here you need to paste the previously copied information about the equipment ID. Next you need to click the button "Search", located to the right of the search bar.

If everything was done correctly, then as a result you will see the model of the video card and you can even immediately download the driver for it. But let's return to the search for drivers a little later.

Method 2: Find out the video card model using the DirectX diagnostic tool

If for some reason the mentioned site does not work, always obtain information about the graphics chip using standard Windows tools.

Method 3: Find out the video card model using the “System Information” tool

How to download a video card driver

After you have found out the model of your video card, you need to install or update the driver for it. There are several ways to do this.

Method 1: Download the driver from the devid.info portal

As mentioned above, after identifying the video card by ID on the devid.info/ru portal, you can immediately download the necessary drivers.

Method 2: Download the driver from the official website

Installing drivers that were downloaded from official sites is the most correct and safe solution. On such sites, information about updates and changes is posted first.

To do this, select the website of the manufacturer of your video card by clicking on the following links
In the appropriate fields you will only need to indicate your device type, series, model and operating system. Quite often these parameters can be determined automatically.
Press the button "Search" and in the page that opens download the driver.

This is what the process of finding a driver for NVidia video cards looks like

In any case, after the required driver has been downloaded, all you have to do is run the installer and wait until it completes its installation or reinstallation operation. To avoid problems in the future, you can create a separate disk or flash drive with the necessary system programs. This will be especially useful when there is no Internet, which also happens quite often.

Hello, dear readers of the blog site. The nineties are long behind us, and technological progress does not stand still, but inexperienced PC users can still be found today.

Most of them have problems installing drivers and understanding what they are needed for.

In this article I will try to bridge this gap in your knowledge. You will learn what a driver is, what tasks it performs and how to install it and see what has already been installed.

Driver - what is it?

From English the word driver is translated as “ conductor».

In reality, a driver is a kind of intermediary between the operating system and the device, designed for their better interaction.

To explain in more official language, which explains, how should she interact with the connected external or internal equipment.

What happens if there is no device driver on the computer

Impossible without drivers. Of course, you can take advantage of the fact that after installing the operating system, you can easily start working with your PC.

But this only happens because drivers for most major devices are installed automatically along with Windows.

When you connect third-party equipment to your computer, you simply cannot interact with it without the help of an explorer program, since the operating system needs to “introduce” the device.

Moreover, this program must be created specifically for a specific PC part or model of third-party equipment.

To make it more clear to you what was described a few lines above, consider two examples:

After installing Windows, the user can see a certain image on the screen thanks to the automatic installation of the basic video card driver. But if you need advanced functionality, you will have to look for the main driver.
Windows does not support sound cards well. If the driver is not installed on it, there will simply be no sound on the device. Of course, this is not as critical as if there was no image displayed on the monitor. However, a computer that is unable to reproduce sound will be extremely limited in functionality.

How to check drivers already installed on a PC

To check for a specific driver on your PC, you need to follow these steps:

How to install drivers for existing devices

In most cases, drivers are installed like regular programs. To do this, simply run the file downloaded from the official website of the device manufacturer and complete the installation process step by step.

That's all, after a couple of minutes you can enjoy the full functionality of your computer or device connected to it. However, this can also be done from Device Manager(see screenshot above), as described in detail in this video:

There is also batch installation methods all necessary drivers when using programs specially created for this:

Which way is better? It all depends on your preferences and desire to immerse yourself in the process. The batch method is the fastest, and the first option (files from the official websites of device manufacturers), although it takes a long time, is the most reliable and with a more stable result. IMHO.

For which devices are they needed?

For most devices connected to a computer to work correctly, you need to install special software. These may include both external and internal. Here is the main list devices for which drivers are needed:

video card;
sound card;
LAN card;
motherboard;
Webcam;
MFPs and printers;
keyboard and mouse (if they have advanced functionality or additional buttons);
most connected devices via USB: smartphones, tablets, e-readers, MP3 players and many others.

Of all the internal devices, there are no drivers except for RAM. The power supply doesn't need them either, but that still doesn't count, since the operating system has no contact with them.

If the device is not complex, then it requires a basic driver. Most of them are installed by the operating system automatically.

The user must install some additional drivers for more complex devices independently.

Drivers for external devices (printers, mobile phones, cameras, scanners) are usually included with the device: some come with a special disc, and when you connect others to your computer, the software installation process automatically starts.

But what to do if the treasured disk is lost or there is no trace of the utility? An inexperienced user faces a problem: where to get the driver.

The most logical solution is to download it from the manufacturer’s official website.

Let's say you have an NVIDIA GeForce MX150 video card. To ensure that your graphics adapter performs at its best on your PC, follow these instructions:

Go to the official NVIDIA website.
Go to the “Drivers” tab, enter all the requested data to find the required file, including the version of the operating system on your personal computer.
Next, download the proposed file and proceed with the installation process, which was described above.

Proceed in the same way to search for all the necessary drivers for other devices.

Remember that only on the website of the manufacturer of a specific device you can find the latest drivers and protect yourself from viruses. Download files from third-party and little-known resources for such purposes highly not recommended.

The best programs for updating drivers

To make life easier for inexperienced users, there are special free utilities that allow you to regularly update previously installed drivers. Here are several options, each with its own characteristics:

Driver Booster Free;
DriverHub;
DriverPack Solution;
SlimDrivers;
Snappy Driver Installer.

That's all, dear friends. Now you know about such a thing as a driver, what it is and for what purposes it is used. I hope that after reading this article you will have no more questions. And if they arise, do not hesitate to ask in the comments: if not me, then other readers will be able to answer you.

Good luck to you! See you soon on the pages of the blog site

Theory

Let's move a little away from the driver concept and look at the general theory. In order to understand what a driver is in the system, you first need to go through a minimum of theory on the general x86-64 architecture. Why x86, because this particular platform: a) was chosen by me for experiments, b) is the most common in the client segment of Windows operating systems. The features outlined in this section will give us an understanding of many aspects of the operation of both the operating system itself and, accordingly, the drivers within it.

Processor operating modes

The internal structure of any operating system is based on the hardware features of the platform on which it runs. The central link is the processor; x86-64 processors have several operating modes:

Real mode;
Virtual mode;
Protected mode;
Long mode.

At the dawn of the era of development of x86 personal computers, the processor worked in real mode. However, the real mode gradually became a thing of the past, since it had a number of features that made further development of technology impossible: a 16-bit data bus and a 20-bit address bus (addressing limitation), segment addressing with segment sizes of 64 kilobytes (inconvenience of use) address space), lack of access restrictions to the address space. In order to remove existing restrictions, a protected mode was developed, which provided a number of features important for the development of operating systems: “multitasking”, a protection mechanism (access to privileged commands) that provides access control for various sections of code (programs) to each other, a virtual memory model. In protected mode, Intel x86 processors implement so-called protection rings or privilege levels. There are four of them: 0 (most privileged), 1, 2 and 3 (least privileged). Privilege levels are designed to protect kernel-mode code from user programs and user programs from each other, since it can cause malfunctions. However, the Windows operating system does not use all of the listed levels; it uses only two of them: 0th and 3rd.
To make this clearer, here is a simplified diagram of the interaction of Windows components:

As you can see, the internal environment of the Windows operating system is divided into two parts and supports two execution modes:

Custom Mode- unprivileged mode associated with the hardware 3rd ring of processor protection;
Kernel mode is a privileged mode associated with the processor's hardware ring 0 protection;

This feature is perhaps the most important point in understanding the internal structure of Windows: globally, the operating system is divided into two main parts: user mode and kernel mode.

This is worth understanding, realizing and remembering once and for all, since, in fact, this is one of the basic, basic concepts of many modern operating systems.
User modes and kernel mode have the following differences:

Isolated (non-overlapping) virtual address spaces: user mode space occupies the lower part (addresses from to), kernel mode space occupies the upper part (addresses from to);
Different code access privileges to resources (memory, processor, devices, etc.).

The following processes run in user mode:

Subsystem	Description
System Support Processes	Winlogon logon process (winlogon.exe) Local lsass authentication server process (lsass.exe) Service Control Manager Process (services.exe) Session Manager Process (smss.exe) Console process (conhost.exe) Local Session Manager Process (lsm.exe) . . .
Service Processes	Host process for services (svchost.exe) Print Spooler Process (spoolsv.exe) WMI Service Management Process (winmgmt.exe) . . .
Applications	Custom applications (all applications not included in other categories). Task Manager (taskmgr.exe) Explorer (explorer.exe) Management Console (mmc.exe) . . .
Environment Subsystems	Win32 subsystem (csrss.exe, kernel32.dll, advapi32.dll, user32.dll, gdi32.dll, ...) Linux subsystem (lxss.sys, lxcore.sys) POSIX subsystem (psxss.exe, psxrun.exe, posix.exe, psxdll.dll) OS/2 subsystem (os2.exe, os2ss.exe, os2srv.exe) WOW/WOW64 subsystem (wow64win.dll, wow64.dll, wow64cpu.dll) . . .
Interface to kernel functions	Provides control transfer to the kernel for functions that need it. Supported by the ntdll.dll library

In kernel mode the following is executed:

Subsystem	Description
Executive system	I/O Manager Process Manager Thread Manager Virtual Memory Manager Object Manager PnP Manager Power Manager Window Manager . . .
Kernel	initialization of system-critical boot stage drivers, interprocessor synchronization, scheduling and dispatching of processes/threads/interrupts, handling/dispatching of exceptions/errors and some other functions (ntoskrnl.exe, ntkrnlmp.exe, ntkrnlpa.exe, ntkrpamp.exe).
Device Drivers	physical/logical/virtual device drivers: file system, network, disk, etc. drivers.
Windowing And Graphics System	A windowing and graphics subsystem that provides support for Graphic User Interface (GUI) functions. (win32k.sys)
Hardware Abstraction Layer (HAL)	ensures independence from the platform hardware and isolates kernel components from hardware specifics. (hal.dll)

Since any operating system simply must be able to work with hardware, the distribution kit (installation kit/system files) contains drivers for key hardware components, without which the system will literally lose access to the hardware with all the ensuing problems: it will not be able to function or not at all will undergo its own installation procedure. These “internal” drivers are presented in the form of a so-called built-in driver library, which varies in composition from version to version, depending on the stages of hardware evolution and market trends. Drivers from this library, if necessary, are installed during the installation of the operating system, depending on the detection (identification) of certain devices on the computer. In general, during installation, the hardware detection module code detects the devices installed on the computer and checks its library for the presence of comparable drivers. For those devices for which system drivers are present, installation is carried out in automatic (background) mode. Thus, “at the end”, after installing the operating system, we can obtain the minimum set of system drivers necessary for operation, which allows us to organize a functional initial working environment. But it’s worth remembering that you shouldn’t limit yourself to the drivers built into the distribution, since most devices may require drivers provided by the device manufacturer for full functionality.

The question remains: do all kernel mode components really communicate with hardware exclusively through the HAL? are there any exceptions? Many sources on the Internet provide diagrams in which graphics adapter drivers interact with video cards as if “directly,” bypassing HAL. As far as I remember, graphics in some versions of Windows were given the highest priority, so they were allocated to a separate category of devices that work directly with the graphics adapter, and this was done in order to speed up the system's graphical interface.

Interrupt Request Levels (IRQL)

Among the key internal mechanisms that determine the functioning of the Windows operating system, there is a topic that is quite important for understanding the principles of how drivers work, and which is unlikely to be ignored. This mechanism is called interrupt request level(Interrupt Request Level, IRQ Level, IRQL) and is quite difficult to understand, so an in-depth study of it goes far beyond the scope of the material presented, however, in this article we will attempt a brief summary (well, in the future we will highlight a separate article for it). Frankly speaking, I myself am still confused about the concept of IRQL, so I will present my own understanding systematically, step by step, based on the knowledge gained at each stage.
I have always associated the term interrupt with the actual operating mode of the processor, taking me back to the days of the MSDOS operating system, in which everything was quite simple: there was a set of 256 interrupts available through the interrupt vector table. Some of these interrupts were hardware and, accordingly, were generated independently based on some external hardware events, while others were software and, accordingly, could be called from application code. Entries in the interrupt table could be overridden, that is, the interrupt handler vector was available to change at its discretion to its own handling procedure. There were no such concepts as the level of interrupt requests; everything was simple and clear. However, with the evolution of processors and operating systems, first protected mode appeared, and then Windows, from that moment everything began to rapidly become more complicated.
Literally suddenly, in the very first versions of Windows 95/NT, some kind of table appeared (consisting of 32 levels of interrupt requests), the levels of which are graded from the lowest 0 (passive) to the highest 31 (high):

Name	Class	Purpose	Intel x86-64 level
HIGH	Hardware	The highest level. Non-maskable interrupt and other types.	31
POWER	Hardware	Power failure events	30
IPI	Hardware	Interprocessor signal. Interprocessor communication signals.	29
CLOCK	Hardware	System timer tick	28
PROFILE	Hardware	Performance monitoring. Kernel profiling timer (mechanism for measuring system performance).	27
DEVICE	Hardware	DIRQL (Devices IRQL). Hardware device interrupts.	3-26
DISPATCH	Program	Scheduler operations/deferred procedure calls (DPCs).	2
APC	Program	Asynchronous procedure calls.	1
PASSIVE	Program	Passive level. No interruptions. Normal user mode code execution level	0

As you can see, the table above contains a very interesting feature: both software and hardware levels are combined (0-2 are software levels, and 3-31 are hardware).

IRQL is a proprietary software attribute introduced by Microsoft developers. This mechanism does not have any hardware support from the processor. The system independently manages all types of interrupts that occur through a mechanism for mapping the interrupt levels of the hardware interrupt controller (PIC) and its own software levels into a single hardware-independent table of interrupt levels.

It follows from this statement that the model is proprietary, software, and the levels in it are not tied to any hardware specification; this allows the system to assemble hardware and non-hardware types of interrupts into a single hierarchy of priorities. Lower (non-hardware/software) IRQL levels (PASSIVE, APC, DPC/DISPATCH) are used to synchronize operating system software subsystems: trigger scheduling operations, such as thread switching or I/O completion processing. Let's look at them in detail:

0th (lowest) priority IRQL (PASSIVE): is a typical interrupt request level at which work is performed in the operating system, both in user mode and in kernel mode. Code (program) running at this level can be simply interrupted (preempted) by anything: for example, threads executing with the IRQ PASSIVE level are preempted by the scheduler after the time slice allocated for them has expired.
The APC and DPC/DISPATCH IRQL levels are software interrupt levels associated with the scheduler.
1st IRQL level (APC): At this level, so-called APC procedures are executed, that is, procedures that execute asynchronously in the context of a specific thread, in other words, organizing asynchronous I/O, or accessing/waiting for the release of any (external, global) system objects. Using APC functions (for example WaitForSingleObjectEx) in code does not lead to immediate execution of the function; instead, the thread (in the context of which the function is executed) goes into a special status and an APC software interrupt is generated, the function call is placed in an internal queue. The next time it is time for this thread to execute, the scheduled APC function is executed at the APC level. Threads running at the APC level therefore do not receive requests from their own APC level, which the system uses to complete I/O operations.
2nd level IRQL (DPC/DISPATCH):
- used to handle Deferred Procedure Calls (DPC): Deferred procedure calls are callback routines that are deferred for execution until a switch to the IRQL DISPATCH level occurs; Typically, DPCs are requested from high IRQL levels to perform additional work for which CPU time is not critical. This is a pretty important stage for performance, and I'll explain why now. Device drivers try to perform the minimum possible number of operations within their own interrupt service routines (ISRs) so as not to take a long time at the DIRQL level, thereby not blocking other interrupts and ultimately slowing down the entire system.
  The higher the IRQL level, the less capability the process has. This encourages developers to perform only the most necessary operations at a high IRQL level, and perform all other actions at a low level.
  
  If the driver realizes that additional work is required that takes up significant processor time, then it requests DPC and delegates this task to it. When the IRQL level drops to DISPATCH, the driver's deferred function callback occurs and does the rest of the processing. By implementing a similar algorithm at the IRQL DISPATCH level, the driver spends less time at the DIRQL level and, accordingly, reduces the delay time for processing its own interrupt, thereby freeing it up for other system devices.
- used to perform scheduler tasks: As you know, the Windows NT line of operating systems implements preemptive multitasking, which means that each process running in the operating system is allocated a certain amount of time to complete. Since the IRQL of the thread scheduler and DPC is 2, it is higher than the priority of user threads (executing at level 0). In turn, the priority of the scheduler is lower than the priority of hardware interrupts (interrupts from devices), that is, it can be interrupted by hardware interrupts.

Okay, but I still don’t understand why it was impossible to abandon all these levels and make a “flat” queuing model, or perform all these types of tasks as they arrive? Let's simulate a working situation:
Let's imagine some code, for example a small program written on the knee. So we launched it for execution, and accordingly, a process for our program was formed in the system, in the context of which the main thread began to execute. A typical thread (user mode or kernel mode) executes at the lowest level, IRQL PASSIVE. Throughout the execution of a thread, the clock (timer chip) periodically generates its own interrupts to count time intervals, which are used to indicate to the operating system that a specified period of time has passed. The clock interrupt handling procedure is performed at the IRQL CLOCK level, which (if you look at the table) is higher in priority than most levels: both the DISPATCH level, at which the scheduler is executed, and the PASSIVE level, at which our program is executed. Thus, the timer constantly displaces the work of both the scheduler and our program. With each timer tick transmitted, the timer interrupt handling procedure reduces the time slice remaining for our currently executing user thread. When a running thread's time slice drops to zero, the clock interrupt routine generates a DISPATCH interrupt, causing the scheduler to run to select the next thread to run. Upon generation of the DISPATCH level interrupt, the timer interrupt handling procedure finishes executing its code and control returns to the system kernel. The kernel finds the next highest priority interrupt waiting in the request queue. Each interrupt is serviced in turn. When all interrupts above the DISPATCH level have been serviced, the DISPATCH level interrupt routine is executed. This interrupt routine processes the DPC list and then calls the scheduler. The Scheduler detects that the current thread's time slice has been exhausted, that is, reduced to zero, after which the Scheduler executes a scheduling algorithm to select the next thread to run. The code of the thread to be executed will be executed when the system drops to the IRQL PASSIVE level.
This is how priorities are implemented, and, accordingly, preemptive multitasking. Now imagine that you remove the hierarchy of interrupt request levels from the system, how will the system behave in this case? In this situation, it would be unclear what and when to execute; the system would execute all incoming tasks in order of priority, which would lead to the fact that threads could easily preempt the scheduler and thereby completely destroy or completely disable preemptive multitasking, which would entail behind unpredictable operation of the OS. Thus:

IRQL is a level of hardware and software prioritization used for synchronization in operating systems of the Windows family, that is, IRQL levels are the main method used to prioritize all actions performed in the Windows operating system throughout the work cycle.

respectively:

IRQL indicates the priority of code running on the processor with respect to interrupts and other asynchronous (sudden) events.

The purpose of IRQL levels in the system is as follows:

Masking: Raising the interrupt level allows you to mask (mask) lower levels of hardware interrupts on the PIC controller. This allows you to temporarily ignore interrupts that occur at lower levels, thereby gaining time to complete the hardware interrupt handling procedure at this level.
Hardware Synchronization: Synchronizing data between threads running on different processors/cores in a multiprocessor system.
Software synchronization: to determine when various APC/DPC procedures can be serviced, to determine when user mode applications can be serviced.

Thus, at the global level, the IRQL mechanism allows the operating system routine to:

Manage re-entry (re-entry)
Ensure that it can continue to operate without being preempted by some other activity.

Process synchronization is a mechanism that allows you to ensure the integrity of a resource (file, data in memory) when it is used by several processes or threads in random order.

Well, okay, but how does this affect the drivers? We know that drivers can be user mode and kernel mode, respectively, executed in user mode and kernel mode. It follows that:

Driver code can execute at different IRQL levels.

And from here two fairly important conclusions follow:

The driver code is preemptible and interruptible. Like any other code in the system, it can be interrupted at any time after the end of the allocated time slice;
Driver code must use different sets of system functions depending on the IRQL level at which it runs.

Imagine a situation where driver code is running at a low IRQL level, modifies some object (for example, a file.txt file), then another code at a higher IRQL level suddenly interrupts its execution and modifies the same file.txt file with other data. When control returns to our driver, it will continue modifying the file with its own data, thereby overwriting the data received from another source. This will cause the file to enter an inconsistent state. To solve such problems, various system synchronization objects were introduced. In order for kernel-level code to modify certain data types, mutex objects, it must first acquire ownership of locks.

Driver concept

The Windows operating system kernel was not designed to interact with devices independently.

Accordingly, the conclusions following from this statement are obvious: for the interaction of the system with devices, separate interfaces are required, perhaps even a complex set of several interfaces. The driver concept was developed to solve the interfacing problem and is used in the models of most modern systems; it is based on the work of special code in the kernel address space, which ensures interaction of the system kernel with any type of logical/physical devices.
Considering the general orientation of the resource, in this article we will cover the specifics of Windows operating system drivers exclusively. So for Windows drivers, as, in general, drivers of other operating systems, the following statements are true:

Driver is software with which the operating system (user programs, kernel and other components) gain access to the functionality of a certain physical or logical device.

the same, but in other words:

Driver is the interface between user mode code, kernel mode code, and physical/logical/virtual device functions.

One of the above definitions notes an important feature of the driver: it is a mistake to imagine a driver solely in interaction with a physical device, since a driver does not necessarily have to provide access to the functions of any hardware; it can also provide exclusively software functional features. Examples of such solutions are drivers installed into the system by antiviruses, data encryption systems, and monitoring systems. The general algorithm of operation of any driver is as follows: applications, through the functions of a special user interface (in Windows, this is the Win32 API) or I/O requests, indirectly/directly access the functions of the driver of a certain device. The driver, in turn, provides access to the functional features of the device of interest, and also controls the process of interaction between application requests and the device itself. Naturally, the driver must define (describe) all the principles of interaction with the serviced (slave, own) device, there must be a set of data about the managed object, instructions (set of commands) with the help of which the system/user code can correctly initialize the device and start interaction with him.

Loading drivers when the operating system starts

It would be very interesting to see at what stage of the operating system boot does the first Windows driver begin to load and start executing? However, in a detailed presentation, this process is quite non-trivial and for a deep understanding it requires reversing the code of many boot components; in addition, it is necessary to take into account many related points, such as: the boot sequence, determined by the dependency between drivers, due to which drivers can be grouped into so-called " download groups", the driver download itself can be divided into several stages, etc. At the same time, it should be taken into account that there is a large amount of material on the Internet regarding already outdated operating systems, so we will try to update the process of loading Windows drivers using the example (closest to me in spirit) of the Windows 7 operating system. And for starters, it would not hurt to talk about the main Windows kernel components that are actively involved in the driver loading process:

I/O Manager- a kernel mode module, part of the executive subsystem, that controls input/output processes, provides an abstraction of physical and logical devices for user applications and system components, and connects user-mode applications with drivers. Controls the stages of the process of interaction with drivers. All data exchange between the I/O manager and drivers is carried out through calling the driver callback procedures and passing them a standardized IRP data structure, which describes the whole essence of calling the driver;
Dispatcher (manager) Plug-and-Play (PnP Manager)- a kernel mode and user mode module, part of the executive subsystem, responsible for adding, recognizing, and removing devices in the operating system. Part of the kernel mode interacts with the rest of the system components and drivers during the installation (loading) of the software necessary to service the devices present in the system. The user mode part is responsible for interacting with user mode programs (for interactive user interaction) in situations that require installing new drivers or adjusting operating parameters in existing ones. Manages the distribution of hardware resources in the system, also knows how to recognize devices, respond to their connection/disconnection, load the appropriate drivers when new devices are detected;
Service Control Manager (SCM)- a system process responsible for creating, deleting, starting and stopping operating system services and drivers. It also provides: functioning of the event log, support for remote procedure call (RPC) technology;

These two managers, that is, the I/O manager and the PnP manager, actively interact with each other.
Now we will describe the process of loading the operating system, but we will not do this in our usual form, but will briefly note the key points regarding the operation of the described components of the operating system with drivers:

Bootmgr(.efi) loads the winload(.efi) module and passes control to it.
Winload(.efi) scans the registry hive HKEY_LOCAL_MACHINE\System\services and gets a list of all drivers installed on the system. This registry hive contains sections that are mapped to the final drivers; they contain various driver-related parameters, such as Group, Start, Type, LoadOrderGroup, DependOnGroup, DependOnServices, which define certain driver loading criteria.
Winload(.efi) loads drivers critical for the initial stage of loading/functioning of the operating system, such as drive controller drivers, file system drivers. Obviously, such drivers have the highest priority, since they create the basis for loading other drivers, therefore, for these and other reasons, they must be in memory at the time control is transferred to the kernel. Accordingly, they are marked with a special type SERVICE_BOOT_START. Drivers at this stage begin to load depending on the groups to which they belong.
Winload(.efi) loads the kernel directly from the ntoskrnl.exe file and transfers control to it.
The kernel loads the I/O Manager and the PnP Manager.
The I/O manager creates the global catalog. This directory is subsequently used to register device objects.
The PnP manager starts the drivers already loaded into memory at the previous stage (having type SERVICE_BOOT_START), calling the DriverEntry procedure of each driver. At this stage, dependent drivers are also loaded.
The PnP manager builds a system device tree, traverses it starting from the root and loads device drivers that have not yet been loaded.
The PnP manager loads the remaining unloaded device drivers, regardless of the value of the Start parameter. Many of these drivers are of type SERVICE_DEMAND_START.
PnP manager loads drivers with advanced functionality. Such drivers include a video adapter driver, external device drivers, and TCP/IP stack drivers. Such drivers have the SERVICE_SYSTEM_START type.
The kernel loads the Session Manager Subsystem Service (SMSS), which in turn loads the Service Management Manager (SCM). SCM scans the registry hive ( HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services) and, based on the information received, mounts an internal database of services/drivers, creates a software interface for servicing the installed services/drivers. SCM loads "autostart" non-PnP drivers (those of type SERVICE_AUTO_START) as well as any drivers they depend on.

From this entire driver loading algorithm, we need to understand the following basic rules: the driver can be loaded (depending on the stage/class of the driver) using the PnP manager, or using the SCM, but the I/O Manager actively participates in the operation of the driver .

Windows Driver Structure

What might a driver look like in structure? Is this really some special class of programs designed in a very specific way? I, too, once naively thought so, but if you think about it, why would operating system developers complicate their lives and invent a new specialized executable file image format for some nuclear components? It is much easier to adapt an old one that has been debugged for a long time and tested a hundred times.

A driver is a kind of “kernel mode library”, a regular DLL file, in which in the PE header (IMAGE_NT_HEADERS structure, OptionalHeader substructure) the Subsystem field value = 1 (IMAGE_SUBSYSTEM_NATIVE).

The subsystem type can be specified when building the executable module. The native subsystem itself is typical for applications that operate according to rules other than classical ones: at the stage of preparing the image for execution, they do not require initialization of the Win32 subsystem. Among others, the native subsystem is used for kernel mode code, which is what almost all drivers are.

By analogy with a DLL, a driver can be simplified as a set of procedures (called by external applications), each of which is designed to handle a specific type of call to the driver.

Let's make a small digression and talk about such a concept as an object. The fact is that the entire process of functioning of the Windows driver, like any other operating system modules, depends on a variety of system data structures. These structures are managed by the kernel and can contain threads, events, I/O requests, devices, and other entities.

Objects. Data blocks containing records of properties of a particular operating system entity. Managed by a dispatcher (manager) of objects. Many objects have handles (descriptors) that make the object accessible to applications.
Data structures. Data blocks containing records of properties of a particular operating system entity. Managed by the kernel. They differ from objects, however (by inertia) they are also called objects

Therefore (with great force) all internal structures of the Windows operating system are called objects.
Now let's return to the driver procedures, in fact, the so-called driver "procedures" are COM callback objects that process events coming from the corresponding operating system infrastructure objects; it is said that the driver provides the operating system kernel with a COM interface defined by a series of procedures implemented by the driver. Export, that is, publication (declaration) of driver procedures for further access to them from the outside, is performed by registering in the main driver procedure (standard for all drivers), called DriverEntry.

The main purpose of the DriverEntry function is for the driver developer to implement in it the filling of the driver object (structure entries) with pointers to various internal driver procedures that provide this or that functionality. In the DriverEntry procedure, you can set (change) the name of a device object, which is then used by applications to open a device handle and send input/output request packets (IRPs).

The DriverEntry function is actually a global initialization function and is executed once at the driver loading stage. This function can be either extremely simple or contain advanced functionality (additional routines), such as the creation of additional device objects, device polling, additional configuration and initialization phases of the device(s).
After publishing its own functions, the driver becomes the "visible" kernel of the operating system. In order not to complicate an already rather complicated theory, we will assume that from the point of view of the Windows kernel, any device is a kind of abstract “virtual device” that operates with a standardized set of commands and is accessible through internal interfaces. As mentioned above, the kernel of the Windows operating system contains a special executive system module called I/O dispatcher (manager), which provides a single interface for all kernel-mode drivers, including physical device drivers, logical device drivers, and file system drivers. Accordingly, the kernel I/O system manages the drivers, or we can say that the drivers use the I/O Manager interface to provide functionality in the operating system. On the other hand, the driver provides transformation (conversion) of “standard commands” coming from the operating system into commands that the device under its control (if any) “understands”, and vice versa. The I/O manager defines a set of standard routines that can be implemented in the driver because:

The driver contains a set of callback procedures that provide various stages of the I/O process.

For a deeper understanding of what functionality a driver should provide, let's provide a general outline of key driver procedures:

Actually, looking at the diagram above, it becomes clear exactly what types of interaction, namely groups of procedures, should be implemented by the abstract Windows driver. Let us now list some of these procedures:

Initialization - The I/O Manager runs an initialization procedure (called DriverEntry), which is intended to carry out the initial setup of the driver object, register all other driver procedures, configure the slave device, and perform other actions for the benefit of the developer.
Adding a device - adding an (additional) device object. In this procedure, the driver typically creates device objects for each device served by the driver. Typically used for Plug-and-Play drivers.
Processing is a set of dispatching procedures (processing various states). Opening, closing, reading, writing to a device, processing power states, PnP events and system states, as well as some other types of interaction are described in dispatch procedures. In fact, these are basic procedures, since typical I/O operations are processed through dispatch procedures.
Start (beginning) of I/O is the second stage of processing an I/O request to a device, directly starting the I/O of the device. This procedure can be used to begin transferring data to/from the device.
Interrupt service routine - When a device generates an interrupt, the interrupt manager transfers control to this routine.
Handling Deferred Procedure Calls - The DPC procedure takes on the bulk of the interrupt handling work after the ISR has executed. Deferred procedure calls are executed at lower IRQL levels (DPC/DISPATCH) than the ISR procedure itself. A similar algorithm is implemented to avoid blocking other interrupts.
I/O completion routine - A layered driver may have I/O completion routines that notify the completion of IRP processing by the low-level driver.
I/O cancellation routines - If I/O operations can be interrupted, the driver may define one or more such routines. When a driver receives an IRP for an I/O request that can be cancelled, it assigns an IRP cancel procedure, and the IRP goes through various processing steps that the procedure can modify or remove if the current operation is not cancelable.
Fast Dispatch Routine - Drivers that make extensive use of the Cache Manager, such as file system drivers, typically provide similar routines to allow the kernel to bypass typical I/O processing algorithms.
Unload procedure - must be implemented in each driver that works (free/occupy) with system resources in order for the I/O Manager to unload the driver from memory.
Shutdown warning procedure - allows the driver to release all occupied resources when the system shuts down.

It becomes obvious that in the process of developing a Windows driver there is no task to implement the entire set of procedures described above; each driver is unique and the developer is free to provide his own set of implementations supported by the driver. When a driver is loaded into the system using the PnP manager or SCM, the I/O manager creates a driver object in the namespace and calls the driver initialization routine (usually DriverEntry), which performs further initialization steps.

A driver object represents an image of a loaded driver in kernel memory, and the system controls the driver through this object.

The driver object represents the driver code and data in the kernel: among other things, the driver exports the entry points of its procedures through this object. The driver initialization procedure writes the entry points of all exported driver procedures to the attributes of this object. Once loaded, the driver can create device objects to represent devices or even form the driver interface. Most drivers create device objects like this:

PnP drivers create device objects through their add device routines when the PnP manager informs them of the presence of a device they manage.
Non-PnP drivers create device objects when the I/O manager calls their initialization routines.

When creating an object of type "device", the driver needs to assign a name to this object. This newly created object is then placed into the namespace object manager(Object Manager), which, like the I/O manager, is part of the kernel executive subsystem. The object manager is intended to maintain a database of all operating system resources represented as objects. The object name can be defined explicitly by the driver itself, or generated automatically by the I/O manager. By convention, device objects should be placed in the \Device directory of the object manager namespace, which is not accessible to applications via the Win32 API. And in order for the “device” object to become available to applications, the driver must create it in the \GLOBAL?? directory. a symbolic link to the name of this object in the \Device directory. Non-plug-and-play and file system drivers typically create a symbolic link with a well-known name (say, \Device\VMwareKbdFilter). Only after all the above steps the driver becomes “visible” in the system and is available for calling by user applications.

Interaction with the driver

How can a user program interact with a driver in the system? In this case, there are two ways:

Implicit -- call a generic Win32 API function;
Explicit -- direct I/O request to the driver;

Well, in the first case, everything is quite simple, in the application program some ordinary Win32 API function is called (for example, CreateFile), which, then, depending on the target object (file, directory), can call the exchange function with the driver in the chain of its calls. In fact, in this case, the application code does not set out to interact with any driver, simply through a chain of procedure calls, at a certain stage the execution goes into kernel mode and a driver function is called there. All this remains hidden from the developer, but it is possible to track the interaction using debugging tools.
The second case is more interesting; it occurs when calling a driver does not mean an indirect call (by calling a standard function), but transferring a so-called I/O control request using a special function (for example, DeviceIoControl), which, in further, initiates the formation of a block of data called an I/O request packet.

I/O Request Packet (IRP) is a Windows kernel data structure containing information describing an I/O request.

Formally, IRP is a package, but in fact it is a kernel object, that is, a data structure (block) with a set of procedures for the I/O manager, providing data exchange between the program and the driver, or between the driver and the driver. As we have already mentioned, the Windows architecture is designed in such a way that it prohibits direct interaction between a user-mode program and a driver, so such an exchange is reduced to the program sending IOCTL code, which already leads to the I/O manager generating an IRP request packet. It is the I/O manager, as responsible for interaction with drivers, that operates with IRP packets. The I/O manager receives an I/O request from a user program, then generates an IRP and passes it to the appropriate driver.
The IRP consists of two parts:

permanent part;
I/O allocation stack.

In the constant part, the IRP contains the major and (not always) minor function code. Major codes: IRP_MJ_CREATE, IRP_MJ_CLOSE, IRP_MJ_READ, IRP_MJ_WRITE, IRP_MJ_CLEANUP, IRP_MJ_DEVICE_CONTROL, IRP_MJ_INTERNAL_DEVICE_CONTROL, IRP_MJ_SCSI, IRP_MJ_SYSTEM_CONTROL, IRP_MJ _POWER, IRP_MJ_PNP, IRP_MJ_SHUTDOWN. The package also contains an I/O placement stack - a special structure IO_STACK_LOCATION containing certain parameters: this is a set of devices that will process this IRP packet. Moreover, along the stack this packet is transmitted sequentially from device to device. More than one stack placement indicates that the IRP can be processed by multiple drivers. IRP “stack cells” are designed to store “variable” information as the IRP packet moves through the driver stack. The IRP goes through each driver's published routines, each of which retrieves the information it needs from its "own" I/O allocation stack cell. Driver procedures are traditionally called “callback procedures.” As we already mentioned, the DriverEtnry driver initialization function tells the kernel (publishes) the names of these procedures and later the kernel itself calls this or that procedure under certain circumstances.
Unlike a standard program, a driver is not a classical process with its own address space and does not have an execution thread. Instead, the driver function executes in the context of the thread and process in which it was called. The context (code execution space) of the driver depends on who is accessing (calling) the driver. The appeal can be initiated:

Application program (user mode program). In this case, the driver execution context is precisely known, and it coincides with the application program context;
Another (third-party) driver. In this case, the execution context is more difficult to determine; it can be either known or random, it depends on the execution context of the calling driver function.
Hardware/software interrupt. In this case, the execution context is random, since an interruption (and, accordingly, switching to driver code) can occur when executing absolutely any code in the operating system.

Again, unlike the standard program, the driver cannot call standard Win32 API functions; it can only operate functions available in the kernel that begin with the prefixes Ex.. , Hal.. , Io.. , Ke.. , Ks.. , Mm.. , Ob.. , Po.. , Ps.. , Rtl.. , Se.. , Zw.. and some others.

Types (types) of Windows drivers

In the process of evolution and, accordingly, the complication of the driver concept, drivers began to be divided into categories (or types) depending on their purpose. Here are the main ones:

Class Drivers(Class driver) - drivers developed by Microsoft for a specific class of devices.
File system drivers(File System Drivers) - drivers that implement file systems on various types of storage media.
Legacy drivers(Legacy drivers) - “legacy” (structure-compatible with older OS versions) kernel mode drivers that independently directly control the slave device without any additional device drivers. Why do they have this name? Because this is a type of driver preserved from the first versions of the Windows NT line of operating systems.
Bus driver - Drivers that provide the functionality of any computer bus (ISA, PCI, USB, IEEE1394 and others);
Filter drivers(Filter driver) - drivers used to monitor/change the logic of another driver by working with data passing through it.

Top filter drivers(Upper-filter drivers) - a subtype of filter drivers located above the functional driver on the stack. All requests pass through the upper filter drivers, which means that they can change and/or filter information going to the functional driver, and then, possibly, to the device. Examples would be a filter driver that monitors/filters traffic and encrypts/intercepts read/write requests. Such drivers are used in firewalls.
Bottom Filter Drivers(Lower-filter drivers) - a subtype of filtering drivers located below the functional driver on the stack. As a rule, fewer requests pass through such lower filtering drivers compared to other filtering drivers, because most requests are executed and completed by the functional driver itself.

Functional Drivers(Function driver) - drivers that function independently and determine all aspects related to the device.
PnP Driver - a driver that supports Plug-and-Play technology;
Minidriver (miniport, miniclass)(Miniport driver, Minidriver, Miniclass driver) - drivers that handle tasks associated with the end device and use class drivers to control the device. Act as one part of a driver pair, in which this category acts as end device drivers that perform specific device tasks.

According to the level of componentization, drivers are:

Single-level - I/O processing is implemented within a single executable module (driver).
Multi-level - I/O processing is distributed among several drivers.

PnP drivers for Windows are divided into:

Function Driver
Bus driver (bus driver)
Driver-filter (filter-driver)

Windows drivers are graded according to their execution mode:

User mode driver.
Kernel mode driver.

Driver models

Throughout the existence of the operating system, developers have tried to standardize and simplify driver development. As a result, models appeared.

Model WDM

Once upon a time, there were two main directions in the development of the Windows driver concept:

Windows 95/98 used the VxD (Virtual Device Driver) model;
in Windows NT3.51, the NT driver model (NT-style driver, NT Driver) was developed in parallel.

However, starting with version Windows 98/NT4.0, developers made an attempt to unify (universalize) driver development, as a result of which the mentioned models were replaced by the new WDM model.

WDM (Windows Driver Model) is a unified development environment (framework) for device drivers of the Windows operating system. It was created to reduce code standardization of driver requirements.

The WDM model was a redefinition of the classic Windows driver stack to support the then revolutionary Plug-and-Play and ACPI technologies. The model makes it possible to load/unload drivers on the fly, without the need to reboot the operating system, develop drivers in the form of extensions (filters) to standard system drivers, manage energy saving and device configuration more flexibly, and so on.
Within the WDM model, any hardware device is supported by at least two drivers:

Function driver - responsible for almost all the functional features of the device being serviced: I/O operations, interrupt handling and device control;
Bus driver - is responsible for maintaining the connection between the device and the computer, in fact supporting the communication bus (for example, PCI, USB and others).

Model WDF

Throughout its development, the WDM model has undergone many changes, growing significantly. Starting with Windows Vista, another attempt was made to develop the Windows driver concept, essentially the WDM model that already existed at that time, which resulted in a new model (add-on to WDM) called WDF.

WDF (Windows Driver Foundation) is a development environment (a set of tools) that facilitates the development of device drivers for Windows operating systems (Windows 2000 and later).

This was due to the indisputable fact that the developers failed to achieve a sufficient level of abstraction of the WDM model, namely the insufficient integration of the I/O subsystem with Plug-and-Play technology and power management. This left the driver developer with a huge burden of synchronizing these I/O requests with Plug-and-Play events and power consumption requests. Obviously, further simplification of the driver model was required. WDF replaced WDM and is considered the most modern model.
WDF implements the following features:

"Moving" some non-runtime-critical driver classes into user mode, which reduced the total number of failures in the kernel.
Much of the I/O interfacing with Plug-and-Play and power management is now handled by the built-in WDF engines.
Providing new internal interfaces to the WDF model that abstract away the more difficult to understand system interfaces; In the WDM/legacy model, it is quite difficult to implement the logic of some parts of interaction with the driver without learning all the basics of the complex kernel architecture, while WDF allows you to automate many types of interaction; A large amount of code when developing a WDM driver can now be replaced by WDF procedure calls.
Possibility of creating a "canonical" driver. The presence of templates that provide a third-party developer with the ability to override criteria unique to his driver, thereby reducing development time.

The WDF model is divided into two directions:

UMDF (Kernel-Mode Driver Framework) is a kernel mode driver development environment.
KMDF (User-Mode Driver Framework) is a user-mode driver development environment.

The division of environments into user and kernel modes in the WDF model is quite arbitrary, since the main purpose of this distinction is to classify the development of drivers for certain classes of devices.

Today we will look at:

There are various reasons why you need a personal computer. This is not always done using programs with automatic selection of drivers.

In addition, you need to know what sound driver you need for your PC for reasons that may degrade the performance of sound devices on your computer.

Sound card not detected by OS

Let's consider cases when the operating system is not able to independently select a driver for the sound card of a personal computer. During the process of reinstalling the system and its further reboot, this is determined by the absence of sound signals.

The reason for creating such a situation may be the installed audio equipment on a personal computer, which: is rare; The release date is older than the OS being installed.
In this case, you need to manually install the sound driver. There are several ways to determine the required sound driver for your PC.

Help Microsoft identify your audio driver

The computer operating system offers assistance in determining the required sound driver. You need to point the cursor to the “My Computer” folder, right-click (RMB), then “Properties”, then “Hardware”. You can make it simpler: right-click the “My Computer” folder and go to the device manager section.

A list will open in the device manager, select the sound card (there is no driver, there is an exclamation mark next to it). Select the line, at the top there is the “Update driver” option, then the “Search for drivers” item, when everything happens with a positive result, the “Install” window will be offered.

Manual search for sound driver

When the automatic selection of a sound driver does not work, you need to try to find it manually; to do this, go to any search engine (Google, Yandex). Then in the search bar we enter the name of our sound device on the PC and add “+ driver”, in the window that opens we select the one we need.

What driver is needed for a personal computer? This can be easily seen in the Device Manager tab. It is recommended to download the driver from the official website of the manufacturer of the installed motherboard (when the sound card is built into it). It is also suggested to download the driver from a site that specializes in updating this hardware for PCs.

After downloading the driver, go back to the “Device Manager” tab, open “Search for drivers on PC”, indicate the location where you saved it, “Install”.

Installing a sound driver with a program

There are times when it is difficult for a computer user to find a sound driver manually and using the OS, then a special program is offered to search for it. Currently, there are several programs for these purposes: Driver Checker, Sam Drivers, Device Doctor, and other programs.

Working with the interface of programs of this type is understandable and intuitive.

There are different cases in which you need to determine the sound driver for your PC, experts advise:

Determine the model of the installed sound device on the PC (read on the computer). Perhaps the lack of sound is due to the hardware not being installed and its use being prohibited in the BIOS.
When the sound is integrated on the PC, it is recommended to download the sound driver only from the website of the motherboard manufacturer, or, in the case of a separate installation of the sound card, write off the chip markings from it. Use the marking search system to find the required driver.
It is recommended to use the AIDA 64 program, it will not only show the required sound driver, but also all installed equipment, you can also determine the chip markings.