Process Explorer course

DLL View Tabs in Process Explorer

Learn how the Image and Strings tabs in Process Explorer identify loaded DLLs, verify signatures, show memory mappings, and compare disk strings with memory strings.

A DLL (dynamic-link library) is a Windows module containing code and resources that a process can load. Process Explorer's DLL View lists the DLLs and other modules loaded by the selected process. For background, see the Process Explorer DLL View guide.

This lesson focuses on the DLL Properties dialog for one selected module—especially its Image and Strings tabs. These are different from the columns shown in Process Explorer's main process list.

Opening DLL Properties from DLL View

1. Select the process you want to investigate.
2. Open its DLL View so the loaded modules are listed.
3. Select the DLL of interest.
4. Double-click the selected DLL to open its DLL Properties dialog.

The DLL Properties dialog describes one loaded module in the context of the selected process. The Image tab combines information from the file and the process's memory mapping. The Strings tab lets you inspect readable text from the disk image and from the loaded memory image.

The Image Tab

The Image tab presents the selected DLL's file identity, build information, location, architecture, memory-mapping details, and signature-verification controls. This combination helps distinguish two files with the same or similar filename. A full path, version, bitness, and runtime address are more useful for identification than a filename alone.

File identity and metadata

• Description: A human-readable file description stored in the DLL's version metadata.
• Company: A publisher or vendor value from the file metadata. After successful signature verification, Process Explorer can show a verified status associated with this value.
• Version: The file or product version associated with the DLL.
• Path: The full filesystem location of the DLL file.

Description, Company, and Version typically come from the DLL's version resource and related file metadata. They are descriptive claims, not proof of identity or safety. A file can have missing metadata, inaccurate metadata, or metadata that imitates a legitimate vendor. Always interpret these fields alongside the path and signature result.

Build and memory details

• Build Time: A timestamp associated with the DLL image build. Use it as a comparison clue, not as independent proof of when or by whom the file was created.
• Base address: The virtual-memory address where this DLL image is mapped in the selected process. This value is specific to the process and its current execution.
• Image size: The size of the DLL image mapped into the process address space. It describes the mapped image rather than simply the size shown by a file browser.

Base address and image size are especially useful during debugging and memory investigation. They help correlate a module with addresses, memory ranges, and crash or diagnostic data. They can differ between processes or runs, so record the process name and context when documenting them.

DLL architecture

The Image tab identifies whether the DLL is 32-bit or 64-bit. Architecture matters because a module must be compatible with the process environment in which it is loaded. Bitness also affects DLL injection, mixed-bitness troubleshooting, debugging, memory inspection, and which diagnostic tools can inspect the process correctly.

For example, an unexpected 32-bit module in a 64-bit investigation, or an attempted use of a 32-bit diagnostic tool against a 64-bit process, can lead to confusing results. Treat the module's architecture as part of its identity, not merely as a technical footnote.

Digital signature verification

Use the Verify button on the Image tab to validate the DLL's digital signature. A digital signature provides cryptographic publisher and integrity information. When verification succeeds, it supports two related claims: the file was signed by the stated publisher, and the signed file content has not changed since signing.

After successful verification, the Company field can display a verified status indicator. This indicates that the publisher identity is supported through the applicable certificate and trust chain. It does not mean the DLL is automatically safe, appropriate for the current process, or free from unwanted behavior. A legitimate publisher can distribute a vulnerable or unwanted component, and a properly signed module can be abused in an unsuitable context.

A non-verified result can have several explanations:

• The file is unsigned.
• The signature is invalid or the file changed after it was signed.
• The certificate chain cannot be validated in the current environment.
• The certificate is valid but the publisher is not trusted under the applicable certificate policy.
• Signature verification itself failed for an environmental or file-access reason.

The Strings Tab

The Strings tab searches for and displays printable strings associated with the selected DLL. A printable string is a readable sequence of characters; this view includes sequences of at least three printable characters.

Strings can provide useful clues, including:

• Filesystem paths and filenames
• URLs, hostnames, or other endpoints
• Registry paths and value names
• Error messages and diagnostic text
• Command-line fragments
• Product names and feature names
• Embedded configuration clues

A string is evidence about text found in an image, not an explanation of what the module does. A URL may be documentation, a registry path may be unused, and an error message may be part of a normal product.

Image strings versus Memory strings

Image strings are extracted from the DLL file stored on disk. They represent readable text persisted in that file at the time it is examined.

Memory strings are extracted from the DLL image as it exists in the selected process's memory. They represent text visible in the module after it has been loaded into that particular process.

The sets can differ for ordinary reasons. A program may unpack or decrypt content only after loading, generate text at runtime, or modify memory during normal operation. Conversely, the file currently on disk may have been updated after an older copy was loaded. Patched memory and memory-resident data can also produce differences.

A meaningful discrepancy can justify further debugging or security investigation, but neither Image strings nor Memory strings alone establishes maliciousness. Correlate the result with the path, signature, process behavior, version, and other trusted evidence.

Interpreting DLL Results Safely

Use a layered comparison rather than relying on one field:

1. Record the host process name and the selected DLL name.
2. Check the complete path. A familiar filename in an unexpected user-writable directory deserves additional scrutiny.
3. Review Description, Company, Version, Build Time, architecture, base address, and image size.
4. Use Verify and record whether the signature is verified, non-verified, or cannot be validated.
5. Review both Image strings and Memory strings, noting useful paths, endpoints, configuration clues, or diagnostic messages.
6. Assess whether the module makes sense for the host process and its installation location.

Company and Description fields are descriptive metadata. They can be misleading when considered without signature verification and path context. A system-looking filename in a user-writable directory, especially when paired with an unexpected publisher, architecture, or host process, should be investigated rather than accepted because the name looks familiar.

Example: confirming a Microsoft-supplied DLL

1. Select a running process and locate the DLL in DLL View.
2. Double-click it to open DLL Properties.
3. On the Image tab, review the path, description, company, and version.
4. Select Verify and check whether the Company value receives a verified status indicator.
5. Compare the directory with the expected system or application installation location.

A system-looking filename in an unexpected user-writable path deserves additional scrutiny even if its metadata claims a well-known company. The full path and signature result should carry more weight than filename similarity.

Example: comparing disk content with the loaded image

1. Open DLL Properties for the selected module and choose the Strings tab.
2. Review Image strings for text present in the DLL file on disk.
3. Review Memory strings for text visible in the module mapped into the target process.
4. Note meaningful differences and correlate them with signature status, path, process behavior, and version.

For example, a product name may appear in the disk image while a runtime endpoint or decrypted configuration clue appears only in memory. That difference is an investigative signal, not proof of compromise.

Example: investigating an unfamiliar third-party module

Document the DLL path, Company, Version, architecture, Build Time, base address, image size, and signature result. Then search the string output for product names, endpoints, configuration paths, and diagnostic messages. Finally, evaluate the module in relation to its host process and installation location. A third-party DLL can be legitimate yet unexpected, or suspicious despite plausible metadata; context determines the next step.

Troubleshooting Common Results

The DLL cannot be verified as signed by a trusted publisher

Possible causes include an unsigned file, an invalid signature, a file changed after signing, an unavailable certificate chain, or a publisher that is not trusted by the applicable policy.

• Check the DLL path, expected software source, and host process.
• Do not rely only on Company or Description metadata.
• Compare the observed version and location with known-good deployment information.

Image strings and Memory strings do not match

The loaded image may differ from the file currently on disk, the module may have been altered in memory, or code and strings may have been unpacked, decrypted, or generated at runtime. Some differences are normal effects of loading and execution.

Treat the difference as an investigative signal rather than proof of compromise. Correlate it with signature status, module path, process behavior, and other trusted evidence.

A familiar DLL filename appears suspicious

A nonstandard directory may contain a DLL with a name similar to a system or application component. Version-resource fields may also imitate a well-known vendor, or the host process and module architecture may be unexpected.

Prioritize the full path and signature-verification result over filename similarity. Review Company, Version, architecture, and strings for corroborating context.

Expected text is absent from the Strings tab

The text may be shorter than the three-character minimum, encoded, compressed, encrypted, generated dynamically, or located elsewhere in the process rather than in the selected DLL image. Missing strings do not prove that a capability or configuration is absent.

Investigation Notes

When escalating an investigation, document at least the process name, DLL path, version, architecture, verification result, and noteworthy strings. Include whether each string came from the Image or Memory view. This preserves the context needed for another analyst to reproduce and assess the finding.

For related process-level context, see Process Properties, the Security tab, and the Threads tab.