VMware ESXi and vSphere Cluster Management

Understanding DLL Properties Tabs in Process Explorer

Learn how to inspect a loaded DLL in Process Explorer using the Image and Strings tabs, including metadata, signatures, memory layout, and disk-versus-memory string analysis.

A DLL (Dynamic Link Library) is a Windows module that can be loaded by one or more processes. In Process Explorer, a loaded DLL appears as a module belonging to a particular process. The DLL properties dialog helps you inspect that individual module in its current process context.

This lesson focuses on the Image and Strings tabs. Together, they provide file identity, publisher and signature information, runtime memory details, and clues about differences between the DLL stored on disk and the copy loaded in memory.

Opening DLL Properties

Open Process Explorer and select the process of interest.
Display the process's DLL or module view. Depending on the layout and version, this may be the lower pane or a module-focused view.
Locate and select the DLL entry.
Open the selected module's properties through its direct interaction, such as double-clicking it or using its context menu and choosing the properties command.

The resulting dialog describes the selected DLL as loaded into that particular process. It is not a general report about every copy of the same filename on the computer. The path identifies the file used for the module, while the address and size describe that module's mapping in the selected process.

DLL Properties Tab Reference

Tab	Information available	Primary use
Image	File identity, location, version, build metadata, architecture, memory mapping, and verification status	Identify the module, validate its origin, and understand how it is loaded in the process
Strings	Readable text from the disk file and the loaded process memory	Find configuration fragments, URLs, paths, product identifiers, API names, and runtime clues

The Image Tab

The Image tab identifies the module file and summarizes its executable-image metadata. It combines two kinds of information:

File identity information, such as the path, description, publisher, version, and build time.
Runtime memory-layout information, such as the base address and image size in the selected process.

Keeping these categories separate is important. A path and version describe the file that supplied the module. A base address and image size describe how that file is represented in the current process.

Descriptive and Version Metadata

File description: A human-readable description supplied as version-resource metadata.
Company or publisher: The organization named in the file metadata. This field is useful for an initial orientation, but it is not the same as a verified digital signer.
Version: Product or file version information used to compare releases and copies.
Full path: The filesystem location of the DLL that was loaded. This is often one of the most valuable triage fields because an unexpected directory can explain unexpected behavior.
Build time: Timestamp metadata embedded in the executable image. It can help compare builds or copies, but it is not inherently trustworthy and should not be treated as proof of when the file was created.

Runtime Memory Details

Base address: The starting virtual-memory address where the module is loaded in the selected process.
Image size: The amount of process virtual address space occupied by the loaded module image.
Architecture: Whether the module is 32-bit or 64-bit.

The base address and image size describe the DLL's presence in that process, not merely the size of the file on disk. The base address can vary between executions because of address layout randomization and other loader behavior. A different address is therefore not, by itself, evidence that the DLL changed.

Architecture information is useful when diagnosing dependency failures. A 32-bit process generally requires compatible 32-bit modules, while a 64-bit process generally requires compatible 64-bit modules. The displayed architecture can help expose an incorrect dependency or deployment assumption.

Digital Signature Verification

Use the Verify action in the Image tab to evaluate the DLL's code-signing status. A digital signature contains cryptographic publisher and integrity information attached to a file. When Windows accepts the certificate chain and signature, the result can associate the file with its asserted publisher and help detect alteration after signing.

When verification succeeds, the company or publisher display can reflect the verified publisher rather than relying only on descriptive metadata embedded in the file. This distinction matters: a file can claim a familiar company name in its version resource without actually being signed by that organization.

A trusted publisher is a signer whose certificate chain is accepted by the local Windows trust configuration. Trust can be affected by certificate expiration, revocation, missing certificates, policy, or local configuration.

The Strings Tab

The Strings tab extracts human-readable character sequences from both the DLL file and its loaded memory image. In this view, a printable string is a readable sequence meeting the viewer's minimum threshold of four printable characters.

Strings are useful because compiled modules often contain text that reveals how software works or what it expects to find. Examples include:

Configuration fragments and command-line options
URLs, domains, and network endpoint names
Error messages and diagnostic text
Windows registry paths and filesystem paths
API names and imported-function references
Product names, feature identifiers, and version labels

String extraction is a clue-generating technique. It does not reconstruct all program behavior, and the absence of a string does not prove that the corresponding behavior is absent.

Image Strings and Memory Strings

Image strings are printable text extracted from the DLL file stored on disk. They represent content present in the file that Process Explorer reads from its image.

Memory strings are printable text extracted from the loaded DLL image inside the process. They reflect readable text currently present in the module's in-memory representation.

String source	Where data is read	What it can help reveal	Interpretation cautions
Image strings	The DLL file on disk	Embedded URLs, paths, messages, API names, product identifiers, and configuration defaults	May not include data created, decrypted, unpacked, or modified after loading
Memory strings	The DLL image loaded inside the selected process	Runtime-generated text, unpacked content, injected data, modified configuration, and environmental values	Differences can be normal and require process context; readable text alone does not prove malicious activity

Differences between the two lists can point to runtime changes, unpacked or decrypted content, patched code or data, injected data, or environmental state. For example, a domain found only in memory may have been assembled or decrypted after the DLL loaded. A path found only in memory may have been generated from the current user's environment.

These differences are leads, not verdicts. Normal applications generate strings at runtime, load optional components, apply patches, or fill buffers with process-specific information. Assess the strings alongside the process identity, module path, signer, architecture, neighboring modules, and other evidence.

DLL Triage Fields

Field	Question to ask	Example investigative value
Path	Where did the process load this DLL from?	An application directory may be expected; a user-writable or unrelated directory may require explanation.
Company/publisher	Does the stated organization match expectations, and is it verified?	Separates descriptive claims from evidence supported by signature verification.
Version	Is this the expected release?	Reveals outdated, conflicting, or accidentally selected copies.
Build time	How does the embedded timestamp compare with other builds?	Supports version comparison, while recognizing that metadata can be altered.
Base address	Where is the module mapped in this process?	Provides runtime placement context; changing addresses across runs can be normal.
Image size	How much virtual address space does the loaded image occupy?	Helps compare the loaded module with expected builds and memory-layout observations.
Architecture	Is the DLL 32-bit or 64-bit, and does it match the process and dependency requirements?	Helps diagnose loading failures and architecture mismatches.
Signature verification status	Does cryptographic verification support the claimed publisher and file integrity?	Helps distinguish a verified file from one that is unsigned, altered, or not trusted locally.

Investigation Workflow

Confirm the owning process. Start with the process selected in Process Explorer and verify that the module belongs to that process.
Locate the unfamiliar DLL. In the DLL or module view, select the module entry rather than a similarly named file elsewhere on disk.
Open its properties. Use the module's direct properties action to inspect the individual loaded instance.
Review the path and identity. Examine the full path, description, company or publisher, version, and build time. Compare them with the expected installation location and release.
Check architecture and memory placement. Record whether the DLL is 32-bit or 64-bit, then note its base address and image size as runtime details.
Verify the signature. Run Verify and assess whether the publisher is trusted. Do not substitute the company metadata for signature evidence.
Review strings. Look for domains, file paths, product names, registry paths, API names, error messages, and configuration indicators.
Compare both sources. Note strings present only in the image or only in memory. Investigate relevant differences with process context and other endpoint evidence.
Form a conclusion from multiple signals. Use path, signer, version, architecture, process behavior, surrounding modules, and memory findings together.

Practical Examples

Unfamiliar DLL Loaded by a Browser

Select the browser process and locate the unfamiliar module in its DLL view.
Open the module properties and inspect its path, description, company, version, and architecture.
Run signature verification and determine whether the stated publisher is verified.
Review strings for domains, file paths, product names, registry locations, or configuration indicators.
Compare image strings with memory strings before deciding whether the module needs deeper analysis.

A browser-loaded DLL in an unexpected directory, with an unverified publisher and unusual memory-only network strings, deserves more investigation. None of those observations alone establishes compromise.

Unexpected Library Version

Use the Image tab's path and version fields to identify the exact copy selected by the loader.
Compare the displayed location with the expected application or system installation directory.
Use architecture information to check for a 32-bit versus 64-bit mismatch.
Use description, publisher, version, and build metadata as supporting evidence when comparing multiple copies.

Possible explanations include DLL search order selecting another copy, an application-local DLL overriding an installed copy, separate 32-bit and 64-bit dependencies, or multiple versions left after an upgrade.

Possible Runtime Modification

Verify the DLL's digital signature.
Compare readable strings from the disk image with strings found in process memory.
Identify memory-only text and assess whether it suggests unpacked content, runtime configuration, a patch, a hook, or injected data.
Correlate the result with the process identity, module path, signer, architecture, and other loaded components.

Unexpected memory-only strings are a reason to collect additional evidence, not a final verdict. Runtime-generated data and normal application behavior can produce the same observation.

Troubleshooting

The DLL Looks Like It Belongs to a Known Vendor, but Verification Is Not Trusted

The file may be unsigned.
The signing certificate may be expired, revoked, unavailable, or not trusted by the system.
The file may have been modified after signing.
The vendor name in descriptive metadata may not match the actual signer.

Confirm the module path and inspect the signer status instead of relying only on the company name. If appropriate, compare the file with a known-good installation source. Use additional process and endpoint evidence before classifying the file.

Image Strings and Memory Strings Differ

The process may generate or modify data at runtime.
The module may unpack or decrypt content after loading.
A patch, hook, or injected component may have changed memory.
Normal loader or application behavior may account for the difference.

Identify which strings occur only in memory and assess their relevance. Review the DLL path, signer, owning process, and surrounding modules. Do not treat a difference alone as proof of compromise.

The Loaded DLL Is Not the Expected Version

A different copy may have been selected through DLL search order.
An application-local DLL may override a system or product installation copy.
A 32-bit process may have loaded a separate 32-bit dependency.
An upgrade may have left multiple versions on the system.

Use the displayed path and version to identify the copy actually loaded. Check the architecture against the process and deployment requirements. Correct the deployment or dependency path only after confirming which version is intended.

Key Exam Notes

The Image tab combines file metadata with runtime mapping details.
The base address is the module's starting virtual-memory address in a process.
Image size is the virtual address space occupied by the loaded image, not simply the file length.
Base addresses can change between executions because of address layout randomization and loader behavior.
Image strings come from the DLL on disk; memory strings come from its loaded in-memory representation.
Four printable characters is the minimum string length used by the Strings view.
A trusted signature supports publisher identity and post-signing integrity, but it does not prove that the module is safe.
String differences are investigative clues that require context and corroboration.

For a related reference, see Process Explorer DLL view tabs.