Ever wonder what hidden privileges your macOS applications are quietly holding? We did too. That curiosity — along with a real-world security incident we’ll get to in a moment — led the Sysinternals team to build listent, a new command-line tool for macOS that discovers and lists the code-signing entitlements embedded in executable binaries. [github.com]

Sysinternals is a suite of system utilities originally created by Mark Russinovich and Bryce Cogswell in 1996. While Sysinternals made its name on Windows, in recent years the team has been expanding into Linux and macOS — tools like ProcDump for Linux, Sysmon for Linux, and ProcDump for Mac are already out in the wild. Now, with listent 1.0 (published March 26, 2026), we're bringing that same Sysinternals ethos — powerful command-line diagnostics — to the world of macOS entitlement auditing. [github.com] [learn.microsoft.com]

Entitlements are embedded in an app’s code signature and define the capabilities it can request from the system. macOS enforces them as part of its layered security model — alongside sandboxing and user consent. Misconfigure them, and best case your app breaks; worst case, you create a security hole.

The Problem: Why listent Exists

The origin story of listent starts with a surprising security discovery made using another Sysinternals tool.

In 2025, security researcher Koh M. Nakagawa of FFRI Security was experimenting with ProcDump for Mac — our Sysinternals utility for creating process memory dumps. Nakagawa initially assumed the tool would be limited by macOS’s System Integrity Protection (SIP), but something unexpected happened. In Nakagawa’s own words:

“When I heard about this tool, I thought that this tool must be useless because it cannot dump almost all processes due to System Integrity Protection. So, it must be valid only when SIP is disabled. But after downloading this tool and trying it, I noticed something strange. I could dump the process memory, including system processes, even when SIP was enabled. I was shocked about it.” [helpnetsecurity.com]

Digging deeper, Nakagawa discovered that ProcDump for Mac internally calls a macOS utility called /usr/bin/gcore. The problem? Apple had mistakenly granted gcore the com.apple.system-task-ports.read entitlement in macOS 15.0 (Sequoia). This single entitlement gave gcore the ability to read the memory of any process on the system, completely bypassing SIP.

Nakagawa demonstrated three distinct attack scenarios at Nullcon Berlin 2025:

1. Keychain decryption — By dumping the memory of the securityd process, Nakagawa extracted the Master Key used to encrypt the login keychain, allowing full decryption without a user password. [helpnetsecurity.com]
2. TCC bypass — Sensitive files opened by sandboxed apps (PDFs in Preview, contact data in Contacts) could be recovered from those apps’ memory dumps, bypassing Transparency, Consent, and Control protections. [helpnetsecurity.com]
3. FairPlay-encrypted iOS app decryption — On Apple Silicon Macs that run iOS apps natively, Nakagawa was able to dump running iOS app memory and recover decrypted binaries without a jailbroken iPhone. [helpnetsecurity.com]

This vulnerability was tracked as CVE-2025–24204. Apple removed the problematic entitlement from gcore in macOS 15.3.

A single misconfigured entitlement on a legitimate system utility created a gaping hole in macOS security. And here’s what really got us thinking: how would you even notice something like this?

That question — how do we make monitoring entitlements turnkey and easy? — is exactly what drove us to create listent. Rather than relying on ad-hoc manual inspection of code signatures, we wanted a tool that could systematically scan every binary on your system and monitor in real time as new processes launch, surfacing their entitlements instantly. The goal: make the invisible visible, so the next gcore-style misconfiguration gets caught early.

Installation

Getting listent up and running is straightforward. The tool is written in Rust, is open-source under the MIT license, and lives on GitHub at microsoft/Sysinternals-listent. [github.com]

Prerequisites: macOS 10.15+ (Catalina or later) and Xcode Command Line Tools (needed for the codesign utility that listent uses under the hood).

Option 1: Homebrew (Recommended)

We maintain a Homebrew tap for Sysinternals macOS tools. To install listent:

brew tap Microsoft/sysinternalstap
brew install listent

Option 2: Build from Source

If you prefer to compile yourself, you’ll need Rust 1.70 or later (install via https://rustup.rs):

git clone https://github.com/microsoft/Sysinternals-listent.git
cd Sysinternals-listent
cargo build --release

Usage Examples

listent operates in two primary modes — static scanning (audit files on disk) and real-time monitoring (watch processes as they launch). Let's walk through both.

Static Scanning

This is the default mode. Point listent at one or more directories and it will recursively find executable binaries, extract their code-signing entitlements via macOS's codesign, and present the results.

Basic scan (default location):

~ % listent
✓ Processed 1145/1145 files (scanned: 1137, skipped: 8) - completed
...
...
...
/usr/bin/fontrestore:
  com.apple.private.tcc.allow: ["kTCCServiceSystemPolicyAllFiles"]

/usr/bin/footprint:
  com.apple.private.ioaccelmemoryinfo: true
  com.apple.private.iosurfaceinfo: true
  com.apple.private.kernel.get-kext-info: true
  com.apple.private.memorystatus: true
  com.apple.system-task-ports.read.safe: true

/usr/bin/fs_usage:
  com.apple.private.security.system-async-io: true
  com.apple.private.stackshot: true

/usr/bin/gcore:
  com.apple.private.amfi.version-restriction: 1
  com.apple.security.cs.debugger.read.root: true

/usr/bin/gktool:
  com.apple.private.security.syspolicy.package-installation: true

/usr/bin/hdiutil:
  com.apple.private.diskimages.kext.user-client-access: true

/usr/bin/heap:
  com.apple.developer.kernel.extended-virtual-addressing: true
  com.apple.private.dt.instruments.dtservicehub.client: true
  com.apple.private.iosurfaceinfo: true
  com.apple.private.security.storage.AppDataContainers: true
  com.apple.rootless.datavault.metadata: true
  com.apple.security.iokit-user-client-class: ["IOSurfaceRootUserClient"]
  com.apple.system-task-ports.read: true
  com.apple.system-task-ports.read.safe: true
...
...
...
Scan Summary:
  Scanned: 1137 files
  Matched: 179 files
  Duration: 5.88s

Running listent with no arguments scans the default directory paths. The output will show each binary that has entitlements, listing the entitlement keys and values, followed by a summary of how many files were scanned and how many matches were found.

Scan specific directories:

Want to audit your entire /Applications folder and the system binaries in /usr/bin? Just pass multiple paths:

listent /Applications /usr/bin

Please note that directories with a large number of files (such as Applications) can take a while to complete scanning.

Filter by entitlement pattern:

You can use the -e flag with glob patterns to search for specific entitlements across all scanned binaries. For instance, want to know which binaries on your system request Apple security entitlements?

~ % listent -e "com.apple.security.*"
✓ Processed 1145/1145 files (scanned: 1137, skipped: 8) - completed
...
...
...
/usr/bin/app-sso:
  com.apple.security.application-groups: ["group.com.apple.KerberosExtension"]
  com.apple.security.temporary-exception.mach-lookup.global-name: ["com.apple.PlatformSSO.daemon-xpc","com.apple.AppSSO.service-xpc"]

/usr/bin/brctl:
  com.apple.security.application-groups: ["group.com.apple.CloudDocs","group.com.apple.iCloudDrive"]
  com.apple.security.enterprise-volume-access: true

/usr/bin/eslogger:
  com.apple.security.iokit-user-client-class: ["EndpointSecurityDriver","EndpointSecurityExternalClient"]

/usr/bin/hpmdiagnose:
  com.apple.security.iokit-user-client-class: AppleHPMUserClient

/usr/bin/kmutil:
  com.apple.security.ts.tmpdir: true

/usr/bin/ktrace:
  com.apple.security.iokit-user-client-class: ["AppleProcessorTraceUserClient"]

/usr/bin/nc:
  com.apple.security.network.client: true
  com.apple.security.network.server: true

/usr/bin/nscurl:
  com.apple.security.network.client: true

/usr/bin/qlmanage:
  com.apple.security.cs.disable-library-validation: true
  com.apple.security.get-task-allow: true
  com.apple.security.network.client: true
...
...
...
Scan Summary:
  Scanned: 1137 files
  Matched: 76 files
  Duration: 5.90s

The tool supports glob syntax with *, ?, and [] wildcards. You can also combine multiple filters using logical OR — just pass multiple -e flags or comma-separate them:

listent -e "*network*" -e "*debug*"

This would find any binary whose entitlements contain the word “network” or “debug” — important when you want when auditing for overly permissive capabilities.

JSON output for automation:

If you’re integrating listent into a CI pipeline or security automation workflow, add --json for structured output:

~ % listent -e "com.apple.security.*" --json
✓ Processed 1145/1145 files (scanned: 1137, skipped: 8) - completed
...
...
...
  "results": [
    {
      "path": "/usr/bin/IOAccelMemory",
      "entitlements": {
        "com.apple.security.iokit-user-client-class": [
          "IOGPUMemoryInfoUserClient"
        ]
      },
      "entitlement_count": 1
    },
    {
      "path": "/usr/bin/IOMFB_FDR_Loader",
      "entitlements": {
        "com.apple.security.iokit-user-client-class": "IOMobileFramebufferUserClient"
      },
      "entitlement_count": 1
    },
    {
      "path": "/usr/bin/aa",
      "entitlements": {
        "com.apple.security.cs.allow-dyld-environment-variables": false,
        "com.apple.security.cs.disable-library-validation": false
      },
      "entitlement_count": 2
    },
...
...
...

Real-Time Monitoring

The second major mode lets you watch processes as they launch and immediately see their entitlements. This is invaluable for observing system behavior during testing, or for keeping an eye on what’s running in your environment.

Monitor all new processes:

~ % listent monitor
Starting process monitoring (interval: 1.0s)...
Press Ctrl+C to stop monitoring.
[2026-04-14T15:51:07.824202000Z] New process detected: xpcproxy (PID: 80607)
  Path: /usr/libexec/xpcproxy
  Entitlements: com.apple.private.coreservices.canmanagebackgroundtasks, com.apple.private.exclaves.conclave-spawn, com.apple.private.security.storage.driverkitd, com.apple.private.spawn-driver, com.apple.private.spawn-panic-crash-behavior, com.apple.private.spawn-subsystem-root, com.apple.private.xpc.is.xpcproxy

[2026-04-14T15:51:07.824202000Z] New process detected: mdworker_shared (PID: 80605)
  Path: /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdworker_shared
  Entitlements: com.apple.private.accounts.allaccounts, com.apple.private.corespotlight.internal, com.apple.private.corespotlight.sender.importer, com.apple.private.disable-log-mach-ports, com.apple.private.security.restricted-application-groups, com.apple.private.security.storage.Mail, com.apple.private.security.storage.Suggestions, com.apple.private.tcc.allow, com.apple.security.application-groups, com.apple.security.personal-information.addressbook

[2026-04-14T15:51:07.824202000Z] New process detected: mdworker_shared (PID: 80606)
  Path: /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdworker_shared
  Entitlements: com.apple.private.accounts.allaccounts, com.apple.private.corespotlight.internal, com.apple.private.corespotlight.sender.importer, com.apple.private.disable-log-mach-ports, com.apple.private.security.restricted-application-groups, com.apple.private.security.storage.Mail, com.apple.private.security.storage.Suggestions, com.apple.private.tcc.allow, com.apple.security.application-groups, com.apple.security.personal-information.addressbook

Once running, listent continuously polls for newly launched processes and displays their entitlements as they appear. Press Ctrl+C to stop cleanly.

By default the polling interval is 1.0 second, but you can tune it anywhere from 0.1 to 300.0 seconds. For more responsive monitoring:

listent monitor --interval 0.5

Please note that increasing the polling interval will consume more CPU resources.

Monitor with entitlement filtering:

Just like in static scanning, you can filter in real time. Suppose you only want to see processes that request network-related entitlements:

listent monitor -e "com.apple.security.network.*"

For persistent, always-on monitoring, listent can run as a background daemon integrated with macOS launchd. You can start a foreground daemon for testing:

~ % listent daemon run
🚀 listent daemon starting...
✅ listent daemon started successfully
  Polling interval: 1s
  View logs: listent daemon logs
  Check status: listent daemon status
  Stop daemon: listent daemon stop

Or install it as a persistent system service:

sudo listent daemon install

The daemon supports a TOML configuration file for customizing polling intervals, path filters, and entitlement filters. This lets you set up continuous system-wide entitlement monitoring without having to keep a terminal window open — listent quietly runs as a watchdog in the background.

Where Do the Daemon Logs Go?

When running as a background service, listent doesn't write to a separate log file — it uses macOS's Unified Logging System (Apple's modern replacement for the traditional syslog). Specifically, listent logs all its events under the subsystem com.microsoft.sysinternals.listent. All entitlement findings and daemon activity are sent to this system log, which means you can view listent's output using either the standard macOS log command-line tool or via the built-in listent daemon logs convenience commands.

# Stream live listent log entries (info level and above)
log stream --predicate 'subsystem == "com.microsoft.sysinternals.listent"' --level info

# Show all listent log entries from the past hour
log show --predicate 'subsystem == "com.microsoft.sysinternals.listent"' --last 1h

# Filter only error-level entries from listent (past 24h)
log show --predicate 'subsystem == "com.microsoft.sysinternals.listent"' --last 24h

Here is an example of the output from a daemon log:

Filtering the log data using "subsystem == "com.microsoft.sysinternals.listent""
Skipping info and debug messages, pass --info and/or --debug to include.
Timestamp                       Thread     Type        Activity             PID    TTL
2026-04-14 10:26:04.756390-0700 0x161f03f  Default     0x0                  80635  0    listent: [com.microsoft.sysinternals.listent:listent::daemon::logging] New process detected: /Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge | {"entitlement_count":14,"entitlements":["com.apple.application-identifier","com.apple.developer.associated-domains","com.apple.developer.associated-domains.applinks.read-write","com.apple.developer.team-identifier","com.apple.developer.web-browser.public-key-credential","com.apple.security.application-groups","com.apple.security.device.audio-input","com.apple.security.device.bluetooth","com.apple.security.device.camera","com.apple.security.device.print","com.apple.security.device.usb","com.apple.security.personal-information.location","com.apple.security.personal-information.photos-library","keychain-access-groups"],"event_type":"process_detected","name":"Microsoft Edge","path":"/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge","pid":61840,"timestamp":"2026-04-14T17:25:57.314838000Z"}

These commands leverage Apple’s unified log database to fetch listent's records using predicate filtering on the subsystem identifier.

Using the built-in listent daemon logs wrapper:

In practice, the listent daemon logs command is a convenient shorthand that queries the same Unified Logging backend for you. It defaults to showing recent entries, with options for time ranges, output format, and live tailing:

# View daemon logs (default: last 1 hour)
listent daemon logs

# Logs from the last 30 minutes
listent daemon logs --since 30m

# Logs since a specific timestamp
listent daemon logs --since "2025-01-15 10:00"

# JSON output (useful for piping to jq or other tools)
listent daemon logs --format json

# Follow logs in real-time (like tail -f)
listent daemon logs -f

Conclusion

The story of CVE-2025–24204 taught us something fundamental: entitlements are a critical attack surface. A single misconfigured entitlement on Apple’s own gcore utility broke System Integrity Protection, exposed Keychain data, bypassed TCC, and allowed iOS app binary decryption — all without requiring a jailbreak or elevated privileges. And as Nakagawa pointed out, similar issues likely exist in other binaries.

listent is our answer to that risk. Whether you're a developer verifying your app isn't requesting more privileges than it needs, a security researcher hunting for the next entitlement misconfiguration, or an IT administrator auditing your fleet for compliance — listent gives you a fast, flexible lens into what macOS applications can do on your system.

The tool processes everything locally with no network communication so you can run it with confidence on sensitive systems. It’s free, open-source under the MIT license, and we welcome contributions and feedback on GitHub.

Give it a try — run a scan, fire up monitor mode, and let us know what you uncover. Happy entitlements hunting!

We’re thrilled to introduce a new recording format in Sysinternals ZoomIt (v9.2): animated GIFs!

ZoomIt has long supported MP4 recording for high-quality screen captures, but sometimes you need something faster, lighter, and easier to share. That’s where animated GIFs come in.

Why GIF?

Animated GIFs are perfect for quick, loopable screen recordings that:

• Show a short workflow or UI interaction without needing a video player
• Embed easily in emails, bug reports, or documentation
• Auto-play in chat apps and browsers for instant visibility
• Keep file sizes small for fast sharing and loading

Whether you’re demonstrating a repro step, highlighting a UI glitch, or creating a looping tutorial for a teammate, GIFs are a fast and frictionless way to communicate visually.

How It Works

The new feature is available in the Options dialog under the Record tab. Just:

1. Right click ZoomIt in the tray.
2. Select Options > Record.
3. Choose GIF as your recording format.
4. Start recording as usual using the same recording shortcut key!

As with MP4 recording, you can chose to record the full screen, window or a user defined part of the screen using the same recording shortcut keys.

ZoomIt will capture your screen and save the output as an animated GIF, ready to drop into your next Teams message, GitHub issue, or internal doc.

Use Cases

Here are a few ways ZoomIt users might take advantage of GIF recording:

• Developers: Capture a bug repro or UI behavior to share with QA or PMs.
• Support engineers: Show customers how to navigate a setting or reproduce an issue.
• Designers: Share a quick animation of a design prototype or interaction.
• Educators: Create short, looping visual aids for training materials.

Lightweight, Loopable, and Built Right In

This update makes ZoomIt even more versatile for recodring workflows. No need to reach for third-party tools — just record, save, and share.

We can’t wait to see how you use it!

Ever find yourself buried in a deep directory tree, wishing for a quicker way to cd around? We did too. That’s why the Sysinternals team is excited to introduce Sysinternals jcd (jump change directory) – a new open-source tool that turbocharges your command-line directory navigation. In short, jcd is like the traditional cd command, but with superpowers. It’s a Rust-powered utility that lets you jump to directories by typing just a few characters of the name, with smart auto-selection and search capabilities. And yes – jcd is cross-platform and works on macOS as well (so Mac terminal warriors can rejoice too!).

What Problem Does jcd Solve?

Navigating complex file systems can be cumbersome. If you’ve ever spent ages typing out long paths or performing multiple cd .. hops to climb out of directories, jcd is here to save you time. The problem is simple: cd requires an exact path, but sometimes you only remember part of a folder name or you want to quickly jump up or down the directory tree. jcd brings a seamless, integrated solution as part of the Sysinternals suite. It addresses common pain points:

• Partial Name Matching: With jcd, you don’t need to type a full directory name. It will find directories by substring.
• Jumping Up and Down: Unlike cd, jcd searches both down into subfolders and up the directory tree for matches. That means you can also ascend to a parent directory by name.
• Smart Selection with Tab Completion: What if multiple directories match your query? jcd has you covered with an interactive tab completion system. Type a partial name and hit Tab — jcd will cycle through the possible matches, showing each match in turn.
• Case Sensitivity Control: By default, searches are case-sensitive (just like your filesystem). But if you’re not sure about capitalization, jcd offers the -i flag for case-insensitive matching.
• Ignore Junk Directories: One of jcd’s superpowers is ignoring directories that you probably don’t want to dive into. Build outputs, dependency folders, caches — e.g. node_modules, target, bin, etc. – can clutter your search. jcd uses ignore patterns (similar to a gitignore) to skip these by default.

In essence, jcd streamlines the act of changing directories, turning it from a tedious chore into a quick jump. It’s especially handy for developers, DevOps engineers, or anyone who frequently works in deeply nested terminal paths. No more losing your flow because you had to painstakingly navigate the filesystem.

Installation and Setup

Because jcd is part of the Sysinternals suite, we’ve made installation as easy as possible on popular platforms. You can of course build from source if you like (see the BUILD.md in the repo for instructions), but most users can install a ready-made package through the varius package managers. For example, to install jcd on Ubuntu, first register the Microsoft package feed, then install jcd using apt:

# 1. Register the Microsoft apt repository and key  
wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb  
sudo dpkg -i packages-microsoft-prod.deb  

# 2. Install jcd from the repo  
sudo apt-get update  
sudo apt-get install jcd

Once installed, you need source jcd : source /usr/bin/jcd_function.sh

On macOS: We’ve made jcd available via Homebrew for Mac users. If you use Homebrew (a popular package manager on Mac), you can install jcd in two quick steps. First, add the Sysinternals tap (if you haven’t before), then install jcd :

# Add the Sysinternals Homebrew tap (if not done already)
brew tap microsoft/sysinternalstap

# Install jcd via Homebrew
brew install jcd

Once jcdis installed, the last step you will need to do is source the jcd_function.sh file:

source /opt/homebrew/bin/jcd_function.sh

Usage Examples: Jumping Around with jcd

Let’s walk through a few scenarios to demonstrate jcd in action. Once you’ve installed it, you invoke jcd by typing jcd followed by part of the directory you want to go to. Here are some common uses:

• Suppose you have a directory somewhere under the current path called ProjectApollo. Instead of typing the whole name or navigating step by step, just do: jcd Proj by tab and jcd will search the current directory, subdirectories, and also parent directories for any directory name containing Proj. In this case, it will find ProjectApollo.
• Now imagine you have two directories, frontend and frontend-old, in the same folder, and you want to jcd to one of them. You type: jcd front and hit Tab. jcd will complete to frontend/ first, but if that’s not the one you wanted, just hit Tab again to cycle to frontend-old/. You can also toggle back and forth with Shift+Tab. This interactive cycling through matching directories is a huge time-saver. It’s like a mini navigation menu right in your terminal. Once the suggestion showing is the directory you want, press Enter, and you’ll teleport to that directory. No more ambiguity when multiple folders share similar names!
• Case-Insensitive Search: By default, if you search for jcd src, it will match srcexactly (and Srcor SRCwould not match). If you don’t recall the exact capitalization, use the -i flag: jcd -i src which results in a case insensitive search.
• Jump to Parent by Name: jcd isn’t limited to searching downward. It can also look upward. Let’s say you are deep inside projects/webapp/src/utils/ and you want to quickly go back to the projects directory near the top. Simply run: jcd projects and jcd will detect that projects is an ancestor directory and instantly take you up to projects. This saves you from doing cd ../../.. multiple times or retyping the full path. This up-tree search is super useful for jumping to a known parent directory by name.

These examples just scratch the surface. Essentially, anytime you know the name (or part of the name) of a directory you want to jump to, jcd <name> will get you there in one command. It’s like an intelligent teleport for your terminal sessions. And because it’s part of Sysinternals, we’ve paid attention to performance – even with lots of files and deep trees, jcd Rust core is optimized to search quickly, so you’re not left waiting long for results (the animated dots will let you know if a search is taking more than a split-second).

Conclusion: Jump into jcd Today

jcd (jump change directory) is a small tool that can have a big impact on your command-line productivity. It removes the friction of moving around complex directory structures, letting you focus on your actual work rather than navigation. We built jcd to scratch our own itch (who hasn’t lost patience with cd at some point?), and we’re thrilled to share it with the community as part of the Sysinternals suite.

You can find the source code, documentation, and installation instructions on the jcd GitHub repo — it’s open source (MIT licensed) and ready for you to try. We welcome feedback, bug reports, and contributions. If you’re on Linux or macOS and spend a lot of time in the terminal, give jcd a go and let us know what you think! We hope it makes your daily workflow just a little bit easier (and a lot faster). Happy jumping through directories!

Symbol resolution in Sysinternals tools is a powerful capability that converts raw memory addresses into human-readable function names — and when available, even source file paths. This feature is indispensable for deep diagnostics, performance tuning, and malware analysis. In this story, we’ll explore some of the challenges involved in symbol resolution, focusing on Process Explorer as a primary example — though the insights apply across other Sysinternals tools that support symbols.

What Is Symbol Resolution?

When a process runs, its threads execute code from various modules — such as EXEs and DLLs. Without symbol resolution, tools like Process Explorer can only display raw memory addresses in call stacks. But with symbol resolution enabled, those addresses are translated into meaningful function names using symbol files (PDBs).

For example, in Process Explorer, if you right-click a process, choose Properties, go to the Threads tab, and double-click a thread, you might see call stack frames like:

ntdll.dll+0x1a2b3
kernel32.dll+0x3c4d5

But once you enable symbol resolution (via Options > Configure Symbols), and point it to the Microsoft Symbol Server, those same entries might now look like:

ntdll.dll!RtlUserThreadStart
kernel32.dll!BaseThreadInitThunk

This instantly reveals what the thread is doing — whether it’s in a system call, looping in user code, or blocked on a synchronization object.

To enable this feature, Process Explorer also requires access to a helper DLL: dbghelp.dll. You can change this path via Options->Configure Symbols:

By default, it looks for this DLL in C:\Windows\System32. This built in Windows version has some limitations that we will explore —and how to work around them—in the sections below.

More Than Just dbghelp.dll: Required Supporting DLLs

While Process Explorer only prompts you to configure the path to dbghelp.dll via Options > Configure Symbols, the reality is that dbghelp.dll relies on additional supporting DLLs to enable full functionality—especially when accessing remote symbol or source servers.

The most important of these are:

• symsrv.dll – Enables symbol server support, including downloading symbols from the Microsoft Symbol Server or a local cache.
• symsrc.dll – Supports source server functionality, allowing tools to retrieve indexed source code.

In this post — and in general discussions — we often refer to “dbghelp.dll” as shorthand for dbghelp.dll and symsrv.dll. To ensure everything works correctly, it's best to keep both of those DLLs in the same folder, and point Process Explorer to that folder when configuring symbol support.

Symbol Resolution and the In-Box Windows dbghelp.dll

Windows includes a built-in version of dbghelp.dll—the library responsible for handling symbol resolution in many tools, including the Sysinternals suite. While convenient, this in-box version has significant limitations:

• It does not support symbol server access, meaning it cannot download symbols from remote sources like the Microsoft Symbol Server.
• It can only resolve symbols from local .pdb files already present on disk.

As a result, if you rely solely on the default dbghelp.dll that ships with Windows (typically located in C:\Windows\System32), tools like Process Explorer are unable to resolve symbols for most system modules. This leads to incomplete stack traces and missing function names, particularly for kernel or user-mode components that don't have local PDBs.

To ensure complete and accurate symbol resolution, it’s recommended to download a newer version of dbghelp.dll and configure Process Explorer to use it via Options > Configure Symbols. Below, we’ll explore a few ways to obtain a newer version of dbghelp.dll.

Installing dbghelp.dll via the Windows SDK Debugging Tools

One of the easiest and most reliable ways to get a newer version of dbghelp.dll is by installing Debugging Tools for Windows, which is included as an optional component in the Windows SDK. These tools include WinDbg, Microsoft’s powerful debugger, as well as an updated version of dbghelp.dll .

When installing the SDK, make sure to select the “Debugging Tools for Windows” component. Once installed, you’ll find dbghelp.dll and its dependencies in the SDK directory—typically under a path like:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\

After installation, open Process Explorer, go to Options > Configure Symbols, and set the Dbghelp.dll path to the location of the newer DLL. For example, on my machine, I point it to:

C:\x64\dbghelp.dll

(Your actual path may vary depending on where you installed the SDK or copied the files)

With this setup, Process Explorer can connect to the Microsoft Symbol Server and resolve function names, even for system modules, providing much deeper visibility into what your processes and threads are doing.

WinDbg from the Microsoft Store

Another convenient way to get the latest version of dbghelp.dll is by installing WinDbg from the Microsoft Store. This modern version of WinDbg includes the same updated symbol-handling DLLs as the Windows SDK version, including full support for symbol servers.

However, there’s a catch: Windows Store apps are sandboxed, meaning their installation directories are protected by the system. As a result, tools like Process Explorer cannot load dbghelp.dll directly from a Store app's directory, even if you know the path—Windows will block access unless the calling process has the necessary permissions.

Workaround: Copy the DLL to a different location

To work around this limitation, you can manually copy dbghelp.dll from the WinDbg Store app’s installation directory to a location you control—such as:

C:\Tools\DbgHelp\

Once copied, open Process Explorer, go to Options > Configure Symbols, and set the Dbghelp.dll path to point to the copied DLL in your local folder.

This lets you benefit from the latest symbol resolution features without needing to install the full Windows SDK, while still avoiding the sandboxing limitations of Store apps.

Getting dbghelp.dll via NuGet

Another way to obtain an up-to-date version of dbghelp.dll—without installing the full Windows SDK or WinDbg—is through the Microsoft.Debugging.Platform.DbgEng NuGet package. This package includes a recent version of dbghelp.dll along with other related debugging libraries.

To use this method:

1. Install the package using a NuGet client (e.g., nuget.exe, Visual Studio, or the dotnet CLI).
2. Extract the contents (you can use a tool like NuGet Package Explorer or manually rename the .nupkg file to .zip and extract it).
3. Locate dbghelp.dll and copy it to a convenient local path.
4. In Process Explorer, go to Options > Configure Symbols and set the Dbghelp.dll path to the location where you placed the extracted DLL.

Please note that you will want to also download the https://www.nuget.org/packages/Microsoft.Debugging.Platform.SymSrv nuget, extract and copy the symsrv.dll to the same location as dbghelp.dll.

This is a lightweight and developer-friendly approach, especially if you’re already using NuGet in your workflow or want to avoid installing large toolsets just for symbol support.

Looking Ahead: Built-in Support for Symbol Resolution

As outlined above, enabling full symbol resolution in Process Explorer today requires installing either the Windows SDK or the WinDbg app from the Microsoft Store — just to get access to the required helper DLL dbghelp.dll. While these workarounds are effective, they aren’t ideal, especially for users who want a streamlined, zero-dependency experience. Furthermore, the Sysinternals tools have always been designed to be xcopy-friendly — requiring no installation — so relying on additional components runs counter to that core philosophy.

To improve this, we’re planning a future update to Process Explorer that will include dbghelp.dll directly in the download package. This means you’ll be able to enable full symbol resolution out of the box—no additional installations required.

We believe this will make advanced diagnostics more accessible and eliminate one of the most common setup hurdles for users who rely on Process Explorer for performance analysis, debugging, and malware investigation.

We’d love to hear your thoughts — whether you’ve run into symbol issues, have suggestions, or want to share how you use this feature.

Your feedback helps guide our roadmap!

In today’s complex software environments, troubleshooting issues can be a daunting task — especially when access to the underlying systems is limited. Sysinternals tools have long been the go-to solution for diagnosing and resolving problems in locked-down production environments. Whether it’s investigating performance bottlenecks or tracking down bugs, these tools provide deep visibility where traditional tools fall short.

This challenge isn’t limited to production systems. In Azure DevOps (ADO), the situation is similar. Access to the build agent nodes is tightly controlled, making it difficult to diagnose failures such as failing unit tests or integration tests. Developers are often left piecing together log files and error messages, hoping to identify the root cause.

That’s why we’re excited to introduce the new Sysinternals ADO Task extension with both the ProcDump and Procmon task — a powerful addition designed to bring the diagnostic power of postmortem analysis to your Azure DevOps pipelines. This new tool enables you to capture insights directly from your build environments without needing direct access to the agent nodes. Whether you’re facing inconsistent test results, performance issues, or other pipeline problems, this task enables you to get to the bottom of the problem faster and more efficiently.

In this story, we’ll explore how this new Sysinternals ADO Task extension can help you troubleshoot ADO pipeline issues with the same power and precision that Sysinternals tools have been delivering in production environments for years.

When Integration Tests Go Wrong: Diagnosing slow tests in ADO

To illustrate the power of the new Sysinternals ADO Extension, let’s dive into a challenging scenario: troubleshooting integration tests that are running too slow.

Imagine you have a pipeline in Azure DevOps that builds your binaries and then runs a series of integration tests to ensure everything is working as expected. But there’s a problem — during these tests, it takes a lot longer to run the tests than expected, causing the tests to timeout. With limited access to the agent nodes, identifying the culprit is a challenge.

This is where the Sysinternals.ProcDump task comes into play. ProcDump is a lightweight, yet powerful utility traditionally used in production environments to capture crash dumps during CPU spikes or application hangs. Now, with the Sysinternals ADO Task, you can leverage this same capability within your Azure DevOps pipelines.

By configuring the Sysinternals.ProcDump task in your pipeline, you can capture a crash dump at the precise moment when CPU consumption spikes or after a certain delay. This allows you to analyze the dump offline, using tools like WinDbg or Visual Studio, to identify the root cause of the issue.

In the next section, we’ll walk through how to set up the Sysinternals.ProcDump task in your pipeline.

Installing the Sysinternals.ProcDump Task Extension

Before you can leverage the power of Sysinternals.ProcDump in your Azure DevOps pipeline, you’ll need to install the extension from the Visual Studio Marketplace.

Step 1: Navigate to the Marketplace

Head over to the Visual Studio Marketplace and search for “Sysinternals”. Alternatively, you can follow this direct link to the extension page.

Step 2: Install the Extension

Click on the “Get it free” button and select the organization where you want to install the extension. Ensure that you have the necessary permissions to install extensions in that organization.

Step 3: Confirm Installation

After installation, the Sysinternals.ProcDump task will be available in your Azure DevOps pipelines. You can now start integrating it into your workflows to capture and analyze crash dumps.

Configuring Your Pipeline to Capture Crash Dumps

With the Sysinternals.ProcDump extension installed, it’s time to integrate it into your Azure DevOps pipeline. In this section, we’ll walk through the configuration needed to capture crash dumps during your integration tests, helping you get to the root cause of slow running integration tests.

Step 1: Add the Sysinternals.ProcDump Task

Open your pipeline YAML file and add the Sysinternals.ProcDump task to the relevant job. This task will monitor your integration tests and capture a crash dump after 15 seconds of runtime. Here's an example of how to do that targeting the ping process.

- task: Sysinternals.ProcDump@1
  displayName: 'Capture Crash Dump with ProcDump'
  inputs:
    processName: 'ping'
    dumpType: 'Full'
    delay: 15
    artifactName: mydumps_windows

• dumpType is set to Full to capture a complete memory dump.
• delay is set to 15, meaning a dump will be captured after an initial delay of 15 seconds.
• artifactName specifies the name of the artifact where the crash dumps will automatically be uploaded.

Step 2: Review and Run the Pipeline

Save the changes to your pipeline YAML and commit them to your repository. Run the pipeline and monitor the output. Once the 15 second delay is reached, ProcDump will capture a crash dump and automatically upload it as an artifact to the artifactName specified making it is trivial to generate and get access to the dump.

Here is an example of a pipeline run:

The resulting dump can be found in the mydumps_windows ADO artifact as shown below.

This setup allows you to easily capture and analyze crash dumps from your integration tests, giving you valuable insights into slow running integration tests.

Complete Usage and Configuration Options for Sysinternals.ProcDump

The Sysinternals.ProcDump ADO task offers a range of input parameters, allowing you to customize its behavior to effectively capture crash dumps from your target processes. Here’s a breakdown of all available options:

The processName input is always required as well as either targetDirectory or artifactName and also a trigger (delay, cpuUsage or memoryUsage).

Capture Deep System Traces with Procmon

Since first releasing the ProcDump task, we’ve now added Procmon as well. This gives you another powerful Sysinternals tool you can run directly inside your Azure DevOps pipelines to capture detailed runtime information when you need it.

With the Procmon task, you can record file system, registry, and process activity during your pipeline run and save the log for offline analysis — making it easier to diagnose tricky issues that only show up in your CI/CD environment.

Here’s a simple example of how to use the new Procmon task in your YAML:

- task: sysinternals.procmon@1
  inputs:
    logFile: myprocmonlog
    artifactName: myprocmonlogs
  displayName: 'Procmon'

This will run Procmon during your job, write the trace to myprocmonlog.pml, and publish it as a pipeline artifact under myprocmonlogs_windows.

With ProcDump and Procmon together, you now have lightweight, proven ways to capture memory dumps and deep system traces as part of your automated troubleshooting workflow — without needing to manually rerun builds to reproduce failures.

Wrapping Up: Unlocking New Debugging Possibilities

The Sysinternals ProcDump and Procmon ADO tasks are powerful additions to your ADO pipeline troubleshooting toolkit, enabling you to capture detailed crash dumps and deep system traces in restricted build environments. By leveraging its flexible configuration options, you can effectively diagnose a range of different issues that would otherwise be challenging to reproduce locally.

But this is just the beginning. The Sysinternals team is exploring expanding our suite of Azure DevOps tasks to help you navigate pipeline issues with the same reliability and efficiency you’ve come to expect from our tools in production environments.

We’re excited to hear about your experiences using the Sysinternals.ProcDump and Sysinternals.Procmon task over at https://learn.microsoft.com/en-us/answers/tags/435/sysinternals. Your feedback is crucial in helping us refine this tool and prioritize future features and tasks. Share your thoughts, suggestions, or any challenges you encounter — we’re all ears!

The Sysinternals ProcDump tool has long been a go-to utility for capturing process memory dumps, especially for diagnosing performance issues like excessive CPU or memory usage. Its key strength lies in its ability to monitor specific conditions and automatically generate dumps when thresholds are breached — ideal for intermittent issues that are hard to replicate.

Previously available on Windows and Linux, ProcDump has now been extended to macOS. With the release of ProcDump 1.0 for Mac, users can enjoy consistent functionality across all three major platforms — Windows, Linux, and macOS. This makes ProcDump a versatile choice for developers and system administrators dealing with cross-platform diagnostics and performance tuning.

A note on security

A memory dump is a detailed snapshot of a process’s memory at a given moment in time. Because it captures the full contents of memory, it may contain highly sensitive information such as passwords, personal identifiers, encryption keys, and other critical data.

To safeguard this information consider using proper access controls, secure storage, limited permissions and retention policies.

Maintaining the confidentiality and integrity of memory dumps is vital to prevent potential data breaches or misuse.

Installing ProcDump on Mac

ProcDump for Mac is now easily installable via Homebrew, the popular package manager for macOS.

Install Homebrew: If you don’t have Homebrew installed, visit brew.sh for step-by-step instructions.

Add the Sysinternals Tap: Once Homebrew is installed, add the Sysinternals tap to access ProcDump and other Sysinternals tools. Run the following command in your terminal:

brew tap Microsoft/sysinternalstap

Install ProcDump: With the tap added, install ProcDump for Mac using:

brew install procdump

Running ProcDump on Mac

Since ProcDump generates a memory dump which contains the memory contents of the target process, we have to run it using sudo.

% sudo procdump
ProcDump v1.0.0 - Sysinternals process dump utility
Copyright (C) 2024 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Sysinternals - www.sysinternals.com
Monitors one or more processes and writes a core dump file when the processes exceeds the
specified criteria.

Capture Usage: 
   procdump [-n Count]
            [-s Seconds]
            [-c|-cl CPU_Usage]
            [-m|-ml Commit_Usage1[,Commit_Usage2...]]
            [-tc Thread_Threshold]
            [-fc FileDescriptor_Threshold]
            [-pf Polling_Frequency]
            [-o]
            [-log syslog|stdout]
            {
             {{[-w] Process_Name | PID} [Dump_File | Dump_Folder]}
            }
Options:
   -n      Number of dumps to write before exiting.
   -s      Consecutive seconds before dump is written (default is 10).
   -c      CPU threshold above which to create a dump of the process.
   -cl     CPU threshold below which to create a dump of the process.
   -tc     Thread count threshold above which to create a dump of the process.
   -fc     File descriptor count threshold above which to create a dump of the process.
   -pf     Polling frequency.
   -o      Overwrite existing dump file.
   -log    Writes extended ProcDump tracing to the specified output stream (syslog or stdout).
   -w      Wait for the specified process to launch if it's not running

Based on the available triggers, let’s say we wanted to generate a core dump when the CPU consumption of a target process with identifier 9036 is above 90%:

% sudo procdump -c 90 9036  

ProcDump v1.0.0 - Sysinternals process dump utility
Copyright (C) 2024 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Sysinternals - www.sysinternals.com

Monitors one or more processes and writes a core dump file when the processes exceeds the
specified criteria.

[15:27:56 - INFO]: Press Ctrl-C to end monitoring without terminating the process(es).
Process:                                top (9036)
CPU Threshold:                          >= 90%
Commit Threshold:                       n/a
Thread Threshold:                       n/a
File Descriptor Threshold:              n/a
Polling Interval (ms):                  1000
Threshold (s):                          10
Number of Dumps:                        1
Output directory:                       .
[15:27:56 - INFO]: Starting monitor for process top (9036)
[15:27:57 - INFO]: Trigger: CPU usage:95% on process ID: 9036
[15:28:07 - INFO]: Core dump 0 generated: ./top_cpu_2024-11-15_15:27:57.9036
[15:28:07 - INFO]: Stopping monitor for process top(9036)

In the example above, ProcDump is configured to monitor until the process exceeds 90% CPU usage. Upon detecting a spike (e.g., at 95%), ProcDump automatically generates a memory dump for analysis.

This is just one example of a trigger (CPU) that ProcDump supports but there are others as well (memory, thread count, file descriptor count). Please note that the first version of ProcDump for Mac does not have full trigger parity, but we are actively working on adding the others as well.

We would love your feedback!

ProcDump’s automated memory dump generation is super powerful. By capturing the memory dump at the moment an issue occurs, ProcDump simplifies root cause analysis, ensuring that transient issues don’t go unnoticed. It’s a great tool for performance troubleshooting and debugging.

We are always looking at adding support for new events and would love to hear from you if there are new events you would be interested in and/or any feedback in general.

You can find us on GitHub here.

Sysinternals ProcDump for Linux is a versatile tool for monitoring processes and creating diagnostics data by allowing the user to set up triggers that generate core dumps when activated. Examples of triggers include CPU, memory, thread, file descriptor, signals, .NET integration and much more.

Recently, I was approached by the Microsoft Browser Support team here at Microsoft. They were trying to understand how they could generate core dumps for Microsoft Edge when the browser was misbehaving. They looked at ProcDump for Linux as a possible answer to the question — “How can we generate core dumps of Microsoft Edge on Linux when it crashes?”

We collaborated with the Microsoft Browser Support team to make sure they were able to use ProcDump for Linux to diagnose Edge problems and as part of that collaboration we added a couple of improvements that we feel will be super useful to everyone wanting to get core dumps for their crashing applications. These improvements were released in ProcDump 3.1 for Linux (https://github.com/Sysinternals/ProcDump-for-Linux/blob/master/INSTALL.md).

Crashing processes

Windows engineers typically think of an application that unexpectedly crashes as having suffered from an unhandled exception. On Linux, things look a little different and uses the concept of signals. Conceptually speaking, a signal is delivered to a process when something of interest has occurred. Examples of signals are SIGINT which is delivered to a process when the user hits CTRL-C or SIGSEGV when the program has accessed a restricted area of memory.

It stands to reason that in order to generate a core dump when a process crashes, we have to determine which signal(s) that we consider to be crashing behaviors. As mentioned earlier, a SIGSEGV is typically considered a crashing behavior where we would like a core dump generated. Another example is SIGABRT that is typically sent when a program experiences an unhandled exception. Fortunately, ProcDump for Linux has had the capability of generating core dumps when a specific signal is encountered using the -sig switch. For example, if we wanted to generate a core dump when a SIGSEGV occurs we can issue the following command line:

$ procdump -sig 11 <pid>

11 is the numerical representation of SIGSEGV. You can find a list of signals and their corresponding numerical representation by running:

$ kill -l

This capability is great when you know which signal is causing the crash, but what happens when you don’t know which signal to target? This was the dilemma that faced the Microsoft Browser Support team and led us to the addition of being able to specify multiple (comma separated) signals. For example, a helpful list of signals include SIGSEGV and SIGABRT:

$ procdump -sig 11,6 <pid>

The above command line generates a dump when either a SIGSEGV or SIGABRT is encountered.

Controlling the size of the core dump

Conceptually, a core dump is a static snapshot of the memory contents of a given process. It can contain a number of different categories of memory such as anonymous private mappings, file-backed private mappings, huge pages and more. Most of the time, the size of the generated core dump will be manageable but there are processes that use a lot of memory. As a result, including everything in the core dump can make them prohibitively large. For example, an application that simply creates an anonymous mapping of 10GB and never uses any of it leads to a core dump of 10GB+. With an excessively large core dump, there may not be enough room to store it and/or transferring the core dump from a production machine can be too expensive.

This was the exact scenario that the Microsoft Browser Support team found themselves in when troubleshooting Microsoft Edge. When Microsoft Edge crashed, the resulting core dump was very large and made it challenging to accurately manage it. As a result, in order to address this issue, ProcDump now includes the -mc switch which allows you to specify the type of memory to include in the dump. The -mc switch takes a hexadecimal number representing a bitmask of the different memory categories. The current list of options are shown below but you can also get the most up-to-date by running man core.

          bit 0  Dump anonymous private mappings.
          bit 1  Dump anonymous shared mappings.
          bit 2  Dump file-backed private mappings.
          bit 3  Dump file-backed shared mappings.
          bit 4 (since Linux 2.6.24)     Dump ELF headers.
          bit 5 (since Linux 2.6.28)   Dump private huge pages.
          bit 6 (since Linux 2.6.28)  Dump shared huge pages.
          bit 7 (since Linux 4.4)  Dump private DAX pages.
          bit 8 (since Linux 4.4)  Dump shared DAX pages.

For example, if we wanted to include only anonymous mappings (both private and shared) and ELF headers, we would end up with the following bitmask:

000010011 (hexadecimal 13)

The ProcDump command line would now look like:

$ sudo procdump -sig 11,6 -mc 13 <pid>

This resuling core dump will be smaller than the default setting. Of course, one caveat to keep in mind is that anytime you remove information from a core dump you also remove the ability to troubleshoot a problem that relies on that diagnostics data being present.

Tip: Microsoft Edge will create multiple processes when browsing the web. In order to know which tab belongs to which process you can use:

…->More tools->Browser task manager

This will open up a new window which lists the different tasks with their corresponding process ID.

Thank You!

This was a fun collaboration between the Microsoft Sysinternals team and Microsoft Support that led to some cool new features that helped them diagnose issues in Edge for Linux.

We’re super excited about these new features and hope that you are as well! We’d love to get your feedback on new feature requests or bugs.

Simply head to our GitHub page — https://github.com/Sysinternals/ProcDump-for-Linux.

Quite often when it comes to generating core dumps based off of memory triggers, we are faced with the challenge of identifying where memory is mysteriously disappearing using just a core dump. Wouldn’t it be awesome to get the call stacks of the leaked memory in addition to the core dump? The newly released ProcDump 3.0 for Linux now has support for both!

Using ProcDump for Linux to track memory

With the release of ProcDump 3.0 for Linux we now have a memory leak tracking capability. Initially we enabled tracking for the malloc family of APIs, but we will extend this in the future to track other memory/resource allocation functions as well.

In order to track memory allocations, ProcDump has a new -restrack switch. This switch tells ProcDump to track memory allocations and produce a leak tracking report every time a core dump is generated. In essence, leak tracking works hand in hand with the existing triggers. This comes in super handy since oftentimes we want the dump and leak report to be generated at the same time (to minimize discrepancies between the two).

Let’s look at an example, suppose we want to track the memory allocations of a test application called testprog. Furthermore, let’s say we want both a core dump and a leak track report to be generated when memory exceeds 3MB:

Here we can see that resource tracking has been turned on (we’ll cover the sample rate later) and ProcDump is waiting for the memory of the target process to exceed 3MB. Once the threshold has been reached, ProcDump outputs the following:

Here we can see that in addition to the core dump we also have a restrack file that contains possible leaked allocations:

(above output has been abbreviated)

The resulting leak tracking file (same name as core dump plus .restrack) consists of one or more allocations that are considered leaked. The first allocation above shows that there has been 0x5c allocations of size 0x2710 each for a total of 0xe09c0 bytes. It also shows the call stack that led to the leaked allocation(s). This information pinpoints exactly where in the application the leak occurred making it much easier to diagnose.

What about false positives?

In the example above, the second allocation also shows as leaked (contains std::vector frames) but it turns out is not actually a leak. The application is utilizing a cache that sticks around for the duration of the application lifetime. In order to avoid having to parse through allocations that are not actually leaks, ProcDump supports the -fx switch which ignores any call stacks with the specified frames. For example, if we run:

sudo ./procdump -m 3 -restrack -fx "*std::_Vector_base<void*, std::allocator<void*> >::_M_allocate*" -w testapp

ProcDump will ignore all allocations whose call stacks contains a frame with the specified string value (wildcards are supported). Running the above in the exact same scenario as above, we now end up with just one leaked allocation:

As you can see, being able to exclude allocations that aren’t true leaks can greatly help reduce the noise and help you more efficiently focus your time.

Sample rate

Generally speaking, the overhead of using resource tracking with ProcDump should be pretty minimal, but in certain circumstances (heavily loaded production workloads), resource tracking can add enough overhead to interfere with the workload. To help reduce this impact, ProcDump also supports a -sr switch (sample rate) which accepts a sampling rate number (default is 1). At the moment, the sampling algorithm simply takes samples every X allocations and reports only on those allocations. For example, using the same scenario as above, only this time we want to sample every 10 allocations, we can run the following:

sudo ./procdump -m 3 -restrack -sr 10 -fx "*std::_Vector_base<void*, std::allocator<void*> >::_M_allocate*" -w testapp

Resulting in the following output:

Here we can see that the allocation count has gone down quite a bit (0x8 vs. 0x51) as a result of only sampling every 10 allocations.

Thank You!

We’re super excited about this new allocation tracking feature and hope that you are as well!

We’d love to get your feedback on both the new allocation tracker as well as all other feature requests or bugs.

You can find us on GitHub here.

We have a new and exciting release of ZoomIt (v7.2) this month which adds:

1. Highlighting
2. Blurring
3. Microphone selection (during screen recording)
4. Automatically copies the recorded video to the clipboard

Highlighting

If you want to draw attention to an area while you are in draw mode, ZoomIt now has highlighting capabilities. While in draw mode, simply press SHIFT and the color of choice (same color choices as with regular drawing) and ZoomIt will now highlight using the selected color. You can use all the available shapes (rectangle, oval etc.) to make highlighting larger areas quick and easy.

Blurring

Blurring is another super useful feature that we added which helps when you want to redact sensitive information in the screen captures. Similar to highlighting, once in draw mode you can simply hit x and use any of the shapes to easily and quickly blur the content.

Microphone selection

Previously, while recording audio during screen recording, ZoomIt always used the default audio device. With this latest release we’ve added the capability of choosing the audio device to be used during the recordings. To select the audio device, simply go to the ZoomIt options dialog under the Record tab.

Copy recording to clipboard

When you take screenshots with ZoomIt, the screenshot is automatically copied to the clipboard making it super easy to share by simply pasting into other applications. With the latest ZoomIt release, screen recordings are also automatically copied to the clipboard making it a snap to share recordings as well.

For example, let’s assume I’ve just finished recording a video using ZoomIt and want to attach the video to an email. I can easily just create a new email and by simply hitting CTRL-V it pastes the video into the email.

Thank You!

We’re super excited about these new features and hope that you are as well! We’d love to get your feedback on new feature requests or bugs. Simply reach out to us at Microsoft Q&A — Sysinternals.

With the release of Sysmon 1.3 for Linux, we are happy to announce that Sysmon for Linux now supports file hashing. This exciting feature was added as a community contribution by eeriedusk via PR #121.

Why is file hashing important?

One of the key ideas behind file hashing is to provide a mechanism by which we can tell if a file has been tampered with. For example, when I execute calc.exe on my system, I get a notification that an instance of calc.exe has been launched. How do I know if that instance represents the Microsoft version of calc.exe that ships with Windows or some other file that just happens to masquerade as the official version (such as a piece of malware)? Enter file hashing. At a high level, a file hash represents a mathematical representation of the contents of a file. If that file changes, so does the hash, allowing us to detect changes to a file that could represent malicious code.

Sysmon for Linux supports SHA-1, SHA-256 and MD5 hashing algorithms.

How do I enable file hashing?

You can enable file hashing in the Sysmon configuration file be specifying the hashing algorithm as shown in the example below:

<Sysmon schemaversion="4.81">
    <HashAlgorithms>md5</HashAlgorithms>
        <EventFiltering>
                <ProcessCreate onmatch="exclude" />
                <RawAccessRead onmatch="exclude" />
                <ProcessTerminate onmatch="exclude" />
                <FileCreate onmatch="exclude" />
                <FileDelete onmatch="exclude" />
        </EventFiltering>
</Sysmon>

Here we enable MD5 hashing for all events that support file hashing. Currently, file hashing is supported for Process Create and File Delete events. Here is an example of a Process Create event:

Event SYSMONEVENT_CREATE_PROCESS
        RuleName: -
        UtcTime: 2023-09-27 15:28:54.094
        ProcessGuid: {b345ea09-4a36-6514-d53b-893dc6550000}
        ProcessId: 716074
        Image: /usr/bin/sudo
        FileVersion: -
        Description: -
        Product: -
        Company: -
        OriginalFileName: -
        CommandLine: sudo tail -f /var/log/syslog
        CurrentDirectory: x
        User: x
        LogonGuid: x
        LogonId: 1000
        TerminalSessionId: 564
        IntegrityLevel: no level
        Hashes: MD5=ea962dfe3798a39f85e7206ec24b2c88
        ParentProcessGuid: {00000000-0000-0000-0000-000000000000}
        ParentProcessId: 512332
        ParentImage: -
        ParentCommandLine: -
        ParentUser: -

You can also specify multiple file hashing algorithms separated by comma as shown below:

<Sysmon schemaversion="4.81">
    <HashAlgorithms>md5,sha256</HashAlgorithms>
        <EventFiltering>
                <ProcessCreate onmatch="exclude" />
                <RawAccessRead onmatch="exclude" />
                <ProcessTerminate onmatch="exclude" />
                <FileCreate onmatch="exclude" />
                <FileDelete onmatch="exclude" />
        </EventFiltering>
</Sysmon>

An example of the corresponding event with both md5 and sha256 enabled is shown below:

Event SYSMONEVENT_CREATE_PROCESS
        RuleName: -
        UtcTime: 2023-09-27 15:51:35.859
        ProcessGuid: {b345ea09-4f87-6514-f12e-7df812560000}
        ProcessId: 719065
        Image: /usr/bin/tail
        FileVersion: -
        Description: -
        Product: -
        Company: -
        OriginalFileName: -
        CommandLine: tail
        CurrentDirectory: x
        User: x
        LogonGuid: x
        LogonId: 1000
        TerminalSessionId: 531
        IntegrityLevel: no level
        Hashes: MD5=4e9e76a4809318e0a0ad4b8292f898b9,SHA256=00483d769f2d15f6d3c0f6f2d9c3c8dde3d377094d8411738f0f3b335008cf84
        ParentProcessGuid: {00000000-0000-0000-0000-000000000000}
        ParentProcessId: 503664
        ParentImage: -
        ParentCommandLine: -
        ParentUser: -

Reach out!

We’d love to get your feedback on Sysinternals Sysmon for Linux and how we can improve.

The repo can be found here — https://github.com/Sysinternals/SysmonForLinux