{
	"id": "804f2e1b-a2e3-44ca-97a5-fefa00814b20",
	"created_at": "2026-04-06T00:06:15.975414Z",
	"updated_at": "2026-04-10T13:12:16.852374Z",
	"deleted_at": null,
	"sha1_hash": "37e4cf59049114dd84cde83ad238719296479323",
	"title": "Dynamic-link library redirection - Win32 apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 76532,
	"plain_text": "Dynamic-link library redirection - Win32 apps\r\nBy stevewhims\r\nArchived: 2026-04-06 00:04:40 UTC\r\nThe DLL loader is the part of the operating system (OS) that resolves references to DLLs, loads them, and links\r\nthem. Dynamic-link library (DLL) redirection is one of the techniques by which you can influence the behavior of\r\nthe DLL loader, and control which one of several candidate DLLs it actually loads.\r\nOther names for this feature include .local, Dot Local, DotLocal, and Dot Local Debugging.\r\nIf your application depends on a specific version of a shared DLL, and another application is installed with a\r\nnewer or older version of that DLL, then that can cause compatibility problems and instability; it can cause your\r\napp to start to fail.\r\nThe DLL loader looks in the folder that the calling process was loaded from (the executable's folder) before it\r\nlooks in other file system locations. So one workaround is to install the DLL that your app needs in your\r\nexecutable's folder. That effectively makes the DLL private.\r\nBut that doesn't solve the problem for COM. Two incompatible versions of a COM server can be installed and\r\nregistered (even in different file system locations), but there's only one place to register the COM server. So only\r\nthe latest registered COM server will be activated.\r\nYou can use redirection to solve these problems.\r\nThe rules that the DLL loader follows ensure that system DLLs are loaded from the Windows system locations—\r\nfor example, the system folder ( %SystemRoot%\\system32 ). Those rules avoid planting attacks: where an adversary\r\nputs code that they wrote in a location that they can write to, and then convince some process to load and execute\r\nit. But the loader's rules also make it more difficult to work on OS components, because to run them requires\r\nupdating the system; and that's a very impactful change.\r\nBut you can use redirection to load private copies of DLLs (for purposes such as testing, or measuring the\r\nperformance impact of a code change).\r\nIf you want to contribute to the source code in the public WindowsAppSDK GitHub repository, then you'll want to\r\ntest your changes. And, again, that's a scenario for which you can use redirection to load your private copies of\r\nDLLs instead of the versions that ship with the Windows App SDK.\r\nIn fact, there are two ways to ensure that your app uses the version of the DLL that you want it to:\r\nDLL redirection. Continue to read this topic for more details.\r\nSide-by-side components. Described in the topic Isolated applications and side-by-side assemblies.\r\nTip\r\nhttp://msdn.microsoft.com/en-US/library/ms682600\r\nPage 1 of 4\n\nIf you're a developer or an administrator, then you should use DLL redirection for existing applications. That's\r\nbecause it doesn't require any changes to the app itself. But if you're creating a new app, or updating an existing\r\napp, and you want to isolate your app from potential problems, then create a side-by-side component.\r\nTo enable DLL redirection machine-wide, you must create a new registry value. Under the key\r\nHKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options , create a new DWORD\r\nvalue with the name DevOverrideEnable. Set the value to 1, and restart your computer. Or use the command\r\nbelow (and restart your computer).\r\nreg add \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\" /v DevOverrideEnable /\r\nWith that registry value set, DotLocal DLL redirection is respected even if the app has an application manifest.\r\nTo use DLL redirection, you'll create a redirection file or a redirection folder (depending on the kind of app you\r\nhave), as we'll see in later sections in this topic.\r\nA packaged app requires a special folder structure for DLL redirection. The following path is where the loader will\r\nlook when redirection is enabled:\r\n\u003cDrive\u003e:\\\u003cpath_to_package\u003e\\microsoft.system.package.metadata\\application.local\\\r\nIf you're able to edit your .vcxproj file, then a convenient way to cause that special folder to be created and\r\ndeployed with your package is to add some extra steps to the build in your .vcxproj :\r\n\u003cItemDefinitionGroup\u003e\r\n \u003cPreBuildEvent\u003e\r\n \u003cCommand\u003e\r\n del $(FinalAppxManifestName) 2\u0026gt;nul\r\n \u003c!-- [[Using_.local_(DotLocal)_with_a_packaged_app]] This makes the extra DLL deployed via F5 get lo\r\n if NOT EXIST $(IntDir)\\microsoft.system.package.metadata\\application.local MKDIR $(IntDir)\\microsoft\r\n if EXIST \"\u0026lt;A.dll\u0026gt;\" copy /y \"\u0026lt;A.dll\u0026gt;\" $(IntDir)\\microsoft.system.package.metadata\\applica\r\n if EXIST \"\u0026lt;B.dll\u0026gt;\" copy /y \"\u0026lt;B.dll\u0026gt;\" $(IntDir)\\microsoft.system.package.metadata\\applica\r\n \u003c/Command\u003e\r\n \u003c/PreBuildEvent\u003e\r\n\u003c/ItemDefinitionGroup\u003e\r\n\u003cItemGroup\u003e\r\n \u003c!-- Include any locally built system experience --\u003e\r\n \u003cMedia Include=\"$(IntDir)\\microsoft.system.package.metadata\\application.local\\**\"\u003e\r\n \u003cLink\u003emicrosoft.system.package.metadata\\application.local\u003c/Link\u003e\r\n \u003c/Media\u003e\r\n\u003c/ItemGroup\u003e\r\nLet's walk through some of what that configuration does.\r\n1. Set up a PreBuildEvent for your Visual Studio Start Without Debugging (or Start Debugging)\r\nexperience.\r\nhttp://msdn.microsoft.com/en-US/library/ms682600\r\nPage 2 of 4\n\n\u003cItemDefinitionGroup\u003e\r\n \u003cPreBuildEvent\u003e\r\n2. Ensure that you have the correct folder structure in your intermediate directory.\r\n\u003c!-- [[Using_.local_(DotLocal)_with_modern_apps]] This makes the extra DLL deployed via Start get loaded\r\nif NOT EXIST $(IntDir)\\microsoft.system.package.metadata\\application.local MKDIR $(IntDir)\\microsoft.syst\r\n3. Copy any DLLs that you've built locally (and wish to use in preference to the system-deployed DLLs) into\r\nthe application.local directory. You can pick up DLLs from just about anywhere (we recommended\r\nthat you use the available macros for your .vcxproj ). Just be sure that those DLLs build before this\r\nproject does; otherwise they'll be missing. Two template copy commands are shown here; use as many as\r\nyou need, and edit the \u003cpath-to-local-dll\u003e placeholders.\r\n if EXIST \"\u003cpath-to-local-dll\u003e\" copy /y \"\u003cpath-to-local-dll\u003e\" $(IntDir)\\microsoft.system.package.metada\r\n if EXIST \"\u003cpath-to-local-dll\u003e\" copy /y \"\u003cpath-to-local-dll\u003e\" $(IntDir)\\microsoft.system.package.metadat\r\n \u003c/Command\u003e\r\n\u003c/PreBuildEvent\u003e\r\n4. Lastly, indicate that you want to include the special directory and its contents in the deployed package.\r\n\u003cItemGroup\u003e\r\n \u003c!-- Include any locally built system experience --\u003e\r\n \u003cMedia Include=\"$(IntDir)\\microsoft.system.package.metadata\\application.local\\**\"\u003e\r\n \u003cLink\u003emicrosoft.system.package.metadata\\application.local\u003c/Link\u003e\r\n \u003c/Media\u003e\r\n\u003c/ItemGroup\u003e\r\nThe approach described here (using an intermediate directory) keeps your source code control enlistment clean,\r\nand reduces the possibility of accidentally committing a compiled binary.\r\nNext, all you need to do is to (re)deploy your project. In order to get a clean, full (re)deployment, you might also\r\nhave to uninstall/clean out the existing deployment on your target device.\r\nIf you're not able to use your .vcxproj in the way shown above, then you can achieve the same ends by hand on\r\nyour target device with a couple of simple steps.\r\n1. Determine the package's installation folder. You can do that in PowerShell by issuing the command Get-AppxPackage , and looking for the InstallLocation that's returned.\r\n2. Use that InstallLocation to change the ACLs to allow yourself to create folders/copy files. Edit the\r\n\u003cInstallLocation\u003e placeholders in this script, and run the script:\r\nhttp://msdn.microsoft.com/en-US/library/ms682600\r\nPage 3 of 4\n\ncd \u003cInstallLocation\u003e\\Microsoft.system.package.metadata\r\ntakeown /F . /A\r\nicacls . /grant Administrators:F\r\nmd \u003cInstallLocation\u003e\\Microsoft.system.package.metadata\\application.local\r\n3. Lastly, manually copy any DLLs that you've built locally (and wish to use in preference to the system-deployed DLLs) into the application.local directory, and [re]start the app.\r\nTo confirm that the correct DLL is being loaded at runtime, you can use Visual Studio with the debugger attached.\r\n1. Open the Modules window (Debug \u003e Windows \u003e Modules).\r\n2. Find the DLL, and make sure that the Path indicates the redirected copy, and not the system-deployed\r\nversion.\r\n3. Confirm that only one copy of a given DLL is loaded.\r\nThe redirection file must be named \u003cyour_app_name\u003e.local . So if your app's name is Editor.exe , then name\r\nyour redirection file Editor.exe.local . You must install the redirection file in the executable's folder. You must\r\nalso install the DLLs in the executable's folder.\r\nThe contents of a redirection file are ignored; its presence alone causes the DLL loader to check the executable's\r\nfolder first whenever it loads a DLL. To mitigate the COM problem, that redirection applies both to full path and\r\npartial name loading. So redirection happens in the COM case and also regardless of the path specified to\r\nLoadLibrary or LoadLibraryEx. If the DLL isn't found in the executable's folder, then loading follows its usual\r\nsearch order. For example, if the app C:\\myapp\\myapp.exe calls LoadLibrary using the following path:\r\nC:\\Program Files\\Common Files\\System\\mydll.dll\r\nAnd if both C:\\myapp\\myapp.exe.local and C:\\myapp\\mydll.dll exist, then LoadLibrary loads\r\nC:\\myapp\\mydll.dll . Otherwise, LoadLibrary loads C:\\Program Files\\Common Files\\System\\mydll.dll .\r\nAlternatively, if a folder named C:\\myapp\\myapp.exe.local exists, and it contains mydll.dll , then\r\nLoadLibrary loads C:\\myapp\\myapp.exe.local\\mydll.dll .\r\nIf you're using DLL redirection, and the app doesn't have access to all drives and directories in the search order,\r\nthen LoadLibrary stops searching as soon as access is denied. If you're not using DLL redirection, then\r\nLoadLibrary skips directories that it can't access, and then it continues searching.\r\nIt's good practice to install app DLLs in the same folder that contains the app; even if you're not using DLL\r\nredirection. That ensures that installing the app doesn't overwrite other copies of the DLL (thereby causing other\r\napps to fail). Also, if you follow this good practice, then other apps don't overwrite your copy of the DLL (and\r\ndon't cause your app to fail).\r\nSource: http://msdn.microsoft.com/en-US/library/ms682600\r\nhttp://msdn.microsoft.com/en-US/library/ms682600\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://msdn.microsoft.com/en-US/library/ms682600"
	],
	"report_names": [
		"ms682600"
	],
	"threat_actors": [],
	"ts_created_at": 1775433975,
	"ts_updated_at": 1775826736,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/37e4cf59049114dd84cde83ad238719296479323.pdf",
		"text": "https://archive.orkl.eu/37e4cf59049114dd84cde83ad238719296479323.txt",
		"img": "https://archive.orkl.eu/37e4cf59049114dd84cde83ad238719296479323.jpg"
	}
}