AppLocker, App Control for Business (WDAC), and Business App Distribution — Before Application Control Blocks You

“We installed it on the customer’s PC and the app will not start. Double-clicking does nothing.” When you distribute a business app, the cause can be not only a defect in the app itself but application execution control in the customer’s environment. Sometimes the exe starts and only the DLLs or scripts shipped with it are stopped.

At that point, rather than changing the signature or the install location straight away, you need to isolate which mechanism stopped which file, and on what grounds.

This article organizes Windows application control from the perspective of the side that builds and distributes the app. After establishing the differences between AppLocker, App Control for Business (formerly WDAC, Windows Defender Application Control), Smart App Control, and SmartScreen, it moves on to the typical blocks, how to read the event logs, and the preparation to do before distribution. It closes with a procedure for the IT department deploying these controls on its own PCs.

1. The Bottom Line First

• Start by distinguishing the four mechanisms, then pin down the target in the log. A SmartScreen warning, AppLocker’s per-user and per-group control, App Control’s machine-wide control, and Smart App Control’s protection for personal PCs are not the same thing. For an exe or DLL under AppLocker the investigation centers on 8004; for App Control it centers on 3077 and the signature information in 3089. For scripts and MSIs, check the other log as well.¹²
• On the distributing side, build an app whose allow rules still match after an update. The core of this is consistent signing that covers not just the exe but the DLLs, the installer, and the bundled scripts. Line up the publisher information, the file attributes, the install location, and the auto-update flow as well. Even on a PC that is not under corporate management, Smart App Control may stop an unsigned app.³⁴
• On the deploying side, let one full business cycle run in audit mode before moving to enforcement. Choose App Control where you can, and use AppLocker where something like per-user control is required. You cannot assume that “the customer’s PCs are Pro, so this does not concern us.” On Windows 10 2004 and later with KB 5024351 and on Windows 11, enforcing AppLocker requires no specific edition, and App Control supports every client edition.³⁵

How to read this by goal

With PowerShell, a script is sometimes not blocked outright but instead runs in Constrained Language Mode, with only part of the processing failing. Section 4 covers this difference too.²

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (36 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Distinguishing the Four Mechanisms

These products have confusingly similar names, so separate them by target, by how they take effect, and by who manages them. Start by working out whether what you face is a warning to be dealt with or a comparison against an administrator’s allow rules.

2.1. SmartScreen — The Only Mechanism That Stops You With a Warning

SmartScreen warns based on a file’s reputation. It works by default with no administrator writing rules, and normally the user can go past the warning and run the file.

That said, if a management policy that forbids clicking through the warning is in effect, SmartScreen becomes an effective block as well. “It is only a warning, so the file can always be run” does not follow.

Keep the countermeasures on the distributing side separate from getting the customer to write allow rules for AppLocker and the like. With SmartScreen, signing and the accumulation of reputation are what matter. This is covered in detail in “Windows SmartScreen and Code Signing”. Sections 2.2 through 2.4 below are mechanisms that block execution rather than warn.

2.2. AppLocker — The Veteran That Can Control Per User

On what grounds, and whose execution, does it control?

AppLocker was introduced in Windows 7. Its rules are based on the attributes of the code signing certificate (the publisher), file attributes derived from the signature metadata (the original file name and version), the hash, and the file path. A policy can be applied not only to the whole computer but to specific users and groups as well.³

Separate “can create rules” from “can enforce them”

The edition requirements are easier to understand once you split those two apart. From KB 5024351 onward, enforcing an AppLocker policy requires no specific edition on Windows 10 version 2004 and later, or on any edition of Windows 11.⁵

On older Windows, on the other hand, a difference by distribution method remains. In environments that include Windows 10 releases before 2004 or Windows Server 2019, the previous conditions still hold: enforcement of a policy distributed by Group Policy is limited to the Enterprise and Server editions, while distribution by MDM works on every edition.⁵

Rules can be created on Pro as well. The earlier restriction was mainly about whether they are enforced, and with MDM distribution even Pro could enforce them at the time. The rule collections — executables, Windows Installer files, scripts, DLLs, and packaged apps — do not vary by edition either.⁵

There is also a prerequisite that has nothing to do with the edition. If the Application Identity service (AppIDSvc) is not running, the rules are not evaluated. Section 6 covers this along with the preparation for auditing.

Where it stands as a security feature

Microsoft states explicitly that AppLocker does not meet the MSRC servicing criteria for a security feature. In other words, if a bypass technique is found, that fact alone is not treated as a security vulnerability. This is another point on which it differs from App Control, covered next.³

2.3. App Control for Business — The Real Answer as a Security Feature

A mechanism that applies to the whole machine

App Control for Business is the current name for the mechanism that was called “configurable code integrity” as part of Device Guard in Windows 10. It was known as WDAC for a long time. Its policies apply to the whole machine and affect every user on that device. This one is designed as a security feature as defined by the MSRC servicing criteria.³

The grounds its rules can use break down as follows.³

Requirements and distribution methods

Policies can be created and applied on any client edition of Windows 10/11, or on Windows Server 2016 and later. For distribution you can use MDM such as Intune, Configuration Manager, or PowerShell. Group Policy can be used as well, but note that it is limited to the single-policy format that works on Windows Server 2016/2019.³

Choosing between this and AppLocker

Microsoft recommends using App Control wherever it can implement what you need. App Control continues to be improved, whereas AppLocker receives security fixes but no new features.³

AppLocker is a good fit when you want to distribute the same policy across a mixed environment that includes older Windows, or when you want different rules per user and group on a shared PC. It can also be used to complement App Control by adding per-user restrictions.³

2.4. Smart App Control — Application Control That Is Already There on Personal PCs

Smart App Control is a protection feature for personal users of Windows 11. At run time it checks a cloud security service’s prediction of safety and looks for a valid signature. It blocks apps judged malicious, as well as apps that have no valid signature and whose trustworthiness cannot be confirmed.⁴

On a new PC it starts in evaluation mode, and Windows decides whether it suits that user before turning it on or off. For users likely to hit blocks often, such as developers, it is turned off automatically.⁴

The point for the distributing side is that application control is at work even on PCs where no IT department has written a policy. Small businesses and sole proprietors among your customers are not exempt. Unsigned apps may be stopped, and Microsoft itself directs developers to sign with a valid certificate. Section 5 covers how to choose a certificate.⁴

3. The Typical Patterns in Which Your App Gets Blocked

Check more than “does the main program start”: check installation, DLL loading, scripts, plug-ins, and auto-update. The patterns that most often cause trouble in custom software development and packaged distribution are these.

The Common Cause Is That the Grounds for the Allow Rules Are Not Stable

What the table has in common is that the distributing side is failing to supply, in a stable form, the grounds the allowing side needs: the signature, the path, or the hash.

Signing only the exe, for instance, means the same publisher rule cannot be used for unsigned DLLs. Allowing them with individual hash rules means the rules have to be updated whenever an update changes the binaries. It can look as though the customer’s controls are the cause when in fact the deliverables or the update method are what make the rules fragile.

Once the symptoms have narrowed the candidates down, use the logs below to establish which file was actually stopped. Working out the fix comes after that.

4. Establish What Happened From the Logs

In the event log, read “the fact that something was stopped” and “what needs fixing” as two separate things. The two entry points are the logs under AppLocker and the CodeIntegrity log, but the important thing is that App Control events are recorded under a log named AppLocker as well.²

4.1. AppLocker Events

Open the log and pick the kind of target

Open Event Viewer by searching for “Event Viewer” in the Start menu, or by entering eventvwr.msc in the Run dialog.¹

Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

On Japanese-language Windows the nodes down to Applications and Services Logs are localized, and everything from the AppLocker provider name downward, EXE and DLL included, stays in English.

To retrieve them with PowerShell, open an elevated session and run the following. This example pulls only exe/DLL audits and blocks from the last 24 hours. Scripts and MSIs are not included.

# Pull AppLocker blocks (8004) and audits (8003) from the last 24 hours
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

Did it match a deny rule, or is an allow rule missing?

The event records the path of the file in question, whether it was allowed or blocked, the rule type (path, hash, or publisher), the rule name, and the SID of the user or group.¹

In allow-list operation, though, most cases are an implicit deny, where the file matched no allow rule at all.

Event 8004 tells you that a block happened and what was blocked, but with an implicit deny the rule name alone will not identify the cause. You have to compare the event against the policy in effect, not just look at the event.

4.2. App Control for Business (WDAC) Events

exe, DLL, and drivers are in a different log from scripts and the like

For control over exe files, DLLs, and drivers, check the CodeIntegrity log below. Control over MSIs, scripts, and COM is recorded in the AppLocker - MSI and Script log mentioned earlier.²

Event Viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational (on Japanese-language Windows only the nodes down to Applications and Services Logs are localized; CodeIntegrity and Operational stay in English)

# View App Control blocks (3077) and audits (3076) together with the matching signature information (3089)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

What this command retrieves is CodeIntegrity 3076, 3077, and 3089. When investigating MSIs, scripts, or COM, follow the table below and check AppLocker - MSI and Script separately as well. While you still do not know which mechanism is involved, line up the logs under AppLocker and CodeIntegrity over the same time range.

Use 3089 to check the signature that was actually evaluated

One 3089 event is generated per signature on the file. For an unsigned file, a single event with a signature count of zero is emitted. It is matched to 3076, 3077, and others by correlation Activity ID.²

Problems such as “we did sign it, but it is being treated as unsigned” or “an old certificate’s signature is still on it” can be confirmed from this signature information. Compare the state of the file you verified on the distributing side against the state of the file that was evaluated on the customer side.

Even with 8029, PowerShell does not necessarily stop completely

Event 8029 indicates that a script was blocked, but the actual enforcement behavior is left to the script host. PowerShell does not stop a script that the policy does not allow outright; it runs it in Constrained Language Mode.²

In this mode, creating .NET objects is broadly restricted. The result is the symptom “the script started, but one line partway through failed.” When investigating a bundled script, do not judge by whether it launched. For the practical side of signing, see “PowerShell Execution Policy and Script Signing”.

Note also that the Windows Server Core edition has no AppLocker - MSI and Script log. When investigating an app on a server, the existence of the log needs attention too.²

5. What the Distributing Side Can Do — Make an App That Is Easy to Write Rules For

The goal is to ship in a state where the customer’s IT department can write stable allow rules. Signing is the central measure, but it does not mean that a signature alone lets the app run regardless of the customer’s policy. There are six things to line up.

This preparation helps with Smart App Control as well. A binary that is signed and has accumulated reputation is less likely to be caught by the automatic blocking on a personal PC.⁴

5.1. Getting a Code Signing Certificate for the First Time

Choose an RSA certificate from a trusted certification authority

When you are distributing to external customers, choose an RSA-based code signing certificate issued by a public (commercial) certification authority. A self-signed certificate or one from an internal CA cannot be validated on a customer PC that does not trust that CA, and it is not supported by Smart App Control either.⁶

Check the algorithm as well. Smart App Control’s signature check does not support elliptic curve cryptography (ECC) signatures. Sign with ECC and the file may be treated as effectively unsigned on personal PCs.⁶

With App Control too, signer-based rules support only RSA (up to 4096 bits). Try to allow an ECDSA signature with a publisher rule and the corresponding 3089 event records VerificationError = 23. Choosing ECC just because “ECC is newer and stronger” leaves you with a compatibility problem against application control.⁷

For publisher rules, OV and EV both work

Public CA certificates come in OV, which validates the existence of the organization, and EV, which involves stricter vetting. AppLocker and App Control publisher rules can be built from either certificate.

App Control has a rule option called Required:EV Signers, but the official documentation says it is not supported at present. There is therefore no reason to choose EV for the sake of the application control discussed here. The relationship with SmartScreen is covered separately in “Windows SmartScreen and Code Signing”.⁷

Budget for private key storage and signing operations, not just the certificate price

The cost varies by CA and validity period. In your estimate, check the price of the token or HSM, or of the CA’s cloud signing service, on top of the certificate itself.

For certificates issued on or after June 1, 2023, the CA/Browser Forum requirements mean that regardless of OV or EV, the private key must be generated and stored in hardware meeting FIPS 140-2 Level 2 or equivalent (an HSM or a USB token).⁸

If you sign automatically in CI/CD, a cloud signing service is often easier to configure than a physical token. Before buying a certificate, it is practical to discuss how the build-to-signing workflow will operate as well.

Sign every binary and add a timestamp

Line up Authenticode signatures not only on the exe but on your own DLL builds, the installer (MSI or setup exe), and the bundled scripts. With signature metadata in place, the customer can write update-resilient rules such as “allow this product from this publisher, regardless of version”.³

A timestamp is added so the signature stays valid after the certificate expires. Here is a minimal example using signtool from the Windows SDK.

:: Sign the file (hash with SHA-256 and add an RFC 3161 timestamp)
signtool sign /fd sha256 /tr <timestamp server URL> /td sha256 /a MyApp.exe

:: Verify the signature (validate under the Authenticode policy and show the details)
signtool verify /pa /v MyApp.exe

Use the timestamp server URL the CA you bought from gives you. If you are using a key on a token or HSM, check the CA’s instructions for the CSP/KSP to specify as well. DLLs and installers are signed with the same command, so make signing and verifying everything the last step of the build.

5.2. Treat Changes to the Certificate and File Attributes as Changes to the Customer’s Rules

Even with consistent signing, a new version is stopped if what the rules compare against changes. What to check is not only the certificate’s subject and chain. The product name, original file name, and version come from each file’s version resource (assembly information), not from the certificate.

App Control’s Publisher is “the PCA certificate (normally one below the root) plus the CN of the leaf certificate”, and FilePublisher adds the FileName attribute of the signed file (OriginalFileName by default) and a minimum version on top of that.⁷

To the customer, changes like these look like “after we updated, it stopped starting in that environment only”. When you change the company name notation, the CA, or the product and file attributes, put a note in the release notes that lists the old and new signature details (subject, issuing CA) side by side, and give advance notice. That lets the customer’s IT department add or update the allow rules.

5.3. Stabilize the Install Location and the Auto-Update Flow

Put executables under Program Files and avoid designs that extract exe or DLL files into %TEMP% or %APPDATA% at run time and launch them there. A design that runs code from a location the user can write to sits badly with path-rule environments.

For auto-update, sign the update package itself, so that a signed binary is replaced by a signed binary. For the details of a safe design, see “Security Design for Auto-Update”.

With distribution through Intune or Configuration Manager, if the customer has configured the distribution agent as a managed installer, binaries that arrive through that route can be allowed as a matter of operation. Distributing through Intune does not allow them automatically; explicit configuration by an administrator is the prerequisite. Providing an MSI that supports silent installation puts that option in the customer’s hands.

5.4. Put the Information Needed to Build Rules in the Deployment Guide

The deployment guide you hand to the customer should state the signature subject, the list of binaries required to run, and the install paths. These are the grounds on which the IT department builds allow rules.

For the case where something is blocked, make it possible to ask them to check by naming the log and event ID from Section 4. This reduces the back-and-forth that starts and ends with “it does not start”, and leaves them able to compare the file and its signature information immediately.

6. Key Points for the Deploying Side (the IT Department)

The basic order for the deploying side is choose the technology, check the impact with an audit, put the allow rules in order and enforce, then keep managing the exceptions. What matters is not to start blocking on every machine at once.

6.1. Choose the Technology by Use Case and Line Up the Prerequisites for Auditing

The default is App Control for Business. Use AppLocker alongside it when per-user control on a shared PC is required, or when older operating systems are in the mix.³ For fixed-purpose PCs such as kiosks, narrowing the use case with a shell restriction first makes the rules simpler. See “Kiosk Mode and Assigned Access” as well.

An audit collects “what would have been blocked under enforcement” without stopping the business. With AppLocker, AppIDSvc must be running; if the service is stopped, no audit events appear either. Configure it to start automatically on the target machines before you begin.

The idea of collecting until the business has gone through one full cycle before moving to enforcement is the same as with SMB signing or NTLM restrictions. Include monthly and annual batch jobs, and do not finish the check with everyday operations alone.

6.2. AppLocker Moves From Audit to Enforcement in Three Steps

1. Enable audit mode. In the Group Policy Management Editor (or secpol.msc locally), open Computer Configuration > Policies > Windows Settings > Security Settings > Application Control Policies > AppLocker. Right-click AppLocker, open Properties, select “Configured” for each rule collection (Executable Rules, Windows Installer Rules, Script Rules, Packaged app Rules) and set it to “Audit only”. Create the default rules in each collection, and configure AppIDSvc to start automatically.

2. Collect events from the log that matches the target. For exe and DLL files it is 8003 in EXE and DLL; for scripts and MSIs it is 8006 in MSI and Script. The command in Section 4.1 covers EXE and DLL only, so it will not pick up 8006. To see both, retrieve the logs separately as follows.¹

    # Collect "what would have been blocked under enforcement" from both logs in audit mode
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   Because Get-WinEvent returns an error for a log with no matching events, this example adds -ErrorAction SilentlyContinue. If there is no output, check the service status, the target log, and the time range you queried. If packaged apps are in scope too, add Packaged app-Deployment and Packaged app-Execution in the same form, and check as far out as the monthly and annual batch jobs.

3. Put the allow rules in order, then switch to enforcement. Review the business-critical files that showed up in 8003 and 8006 and fold them into the allow rules. Then change the same properties dialog to “Enforce rules”. After the switch, watch for blocks in 8004 (exe/DLL) and 8007 (scripts and MSIs).

6.3. With App Control, Remove the Audit Option to Move to Enforcement

Distribute the policy with rule option 3 (Enabled:Audit Mode) in the policy XML. Use the App Control Policy Wizard or the Set-RuleOption cmdlet to set it.⁷

Check the impact on the business in 3076 and 8028, put the allow rules in order, and then remove the audit option to switch to enforcement mode. Microsoft also recommends validating a new policy in audit mode first.⁷

6.4. Tie Unsigned Exceptions to Asset Management

Older business apps that stay unsigned are registered as exceptions with hash rules and managed that way. That list is also the list of assets due for replacement. Do not stop at creating the exception: tie it to asset management and review it every year.

7. Summary

Handling application control comes down to three things: telling the mechanisms apart, establishing the facts from the logs, and building deliverables for which allow rules stay stable.

SmartScreen is basically a warning, but under a policy that forbids clicking through it becomes a block. Treat it separately from AppLocker, App Control, and Smart App Control. AppLocker’s edition restrictions have been relaxed, and App Control works on every client edition. Smart App Control acts on personal PCs too, so “it is Pro” or “they have no IT department” does not make it irrelevant.⁵³⁴

When something does not start, use AppLocker 8004 and App Control 3077 and 3089 as the entry points, and cross-check the script and MSI logs as well. When only part of the functionality fails, check PowerShell’s Constrained Language Mode too.¹²

The distributing side lines up consistent signing of every binary, timestamps, stable publisher information and file attributes, standard install locations, signed auto-update, and a deployment guide. The basic aim is an app for which the customer can easily write allow rules and easily keep them working after an update.

The deploying side lets the business run one full cycle under AppLocker 8003 and 8006 and App Control 3076 and 8028 before moving to enforcement. Getting both distribution and operation right reduces the “it only fails in the customer’s environment” cases.

Related Articles

• Why Windows Shows “Windows protected your PC”
• Security Design for Auto-Update - Why HTTPS Alone Is Not Enough
• Choosing a Windows App Distribution Method - MSI/MSIX/ClickOnce/xcopy/Custom Updater
• PowerShell Execution Policy and Script Signing — A Practical Guide to Graduating From “Papering Over It With Bypass”
• Handling Microsoft Defender False Positives
• Windows Kiosk Mode and Assigned Access
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement

Related Consulting Areas

KomuraSoft LLC handles the development and modification of business apps that run under application control (AppLocker / App Control for Business), the design of distribution and auto-update with code signing built in, and the investigation of cases where an app does not start in a customer environment.

• Windows App Development
• Existing Windows Software Modification and Maintenance
• Bug Investigation & Root-Cause Analysis
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Isn't AppLocker unusable on the Pro edition?

That piece of received wisdom has been updated. From KB 5024351 onward, enforcing an AppLocker policy no longer requires a specific edition on Windows 10 version 2004 and later, or on any edition of Windows 11. The old restriction that "enforcement of a policy distributed by Group Policy is limited to the Enterprise and Server editions" applies only up to Windows 10 releases older than version 2004 and to Windows Server 2019 (and even there, distribution via MDM works on every edition). AppLocker is now a real option even in an environment built mainly on small-business Pro machines.

Should we buy an EV code signing certificate?

From the point of view of AppLocker and App Control for Business publisher rules, you can write a rule based on signer information with either an OV (organization validation) certificate or an EV certificate. Note also that the belief "with EV, the SmartScreen warning is gone from the very first run" is out of date: a file signed with EV now has to be thought about on the same reputation-accumulation basis as one signed with OV (that point is covered in the separate article "Windows SmartScreen and Code Signing"). What matters more than the certificate type is signing every binary with a consistent subject — not just the exe but the DLLs and the installer as well — adding a timestamp, and keeping the publisher information stable across certificate renewals. Publisher rules are written on the basis of that signer information, so if the signing state shifts from release to release, the rules on the customer side break.

Our app appears to have been blocked in a customer environment, but I cannot find anything in the log. Where should I look?

The usual cause is that the log you need is split across two families. An AppLocker block of an exe or DLL appears as event 8004 (8003 in audit mode) in the "AppLocker - EXE and DLL" log, while scripts and MSIs appear as 8007 (8006 in audit mode) in the "AppLocker - MSI and Script" log. A block by App Control for Business (WDAC), on the other hand, appears as event 3077 (3076 in audit mode) in the "CodeIntegrity - Operational" log, with the corresponding signature information recorded in 3089. On top of that, when a script, MSI, or COM object is caught by App Control, it appears in the "AppLocker - MSI and Script" log as 8029, 8036, or 8040. When you are investigating without knowing which mechanism is at work, line up CodeIntegrity - Operational and everything under AppLocker by timestamp and compare them.

What does it take to keep Smart App Control from blocking our app?

In practice, code signing. When an app runs, Smart App Control checks whether a cloud security service can predict that the app is safe and whether the app carries a valid signature, and it blocks apps judged malicious as well as unsigned apps whose trustworthiness cannot be confirmed. Microsoft's own developer guidance also lists signing your app with a valid certificate. The signing algorithm needs attention, though: Smart App Control's signature check does not support elliptic curve cryptography (ECC) signatures, and it is apps signed with an RSA-based certificate that are eligible to run. Smart App Control is not an enterprise management feature but a protection for personal users of Windows 11, and it is turned on or off automatically starting from evaluation mode, so from the distributing side the safe assumption is that an unsigned executable may not run on a personal PC.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.