Why isn't handles.exe discovering my DLL while ProcessExplorer can?

Question

The problem: On a windows server 2012 r2 box, I'm trying to use Chef to programmatically replace a .dll command component (aka a vb 6 library that I've registered on the box using regsvr32.exe) but when I try to copy over the file, the app pool of the website has a lock on it. I'm not sure if it matters, but the w3wp process is set to run as 32 bit via IIS.

My Solution (which isn't working): In order to fix it, I was thinking about using a command line tool to find the reference to the dll and then recycling the app pool that's using it. Unfortunately, while I can get SysInternals' process explorer to find the dll, Handles.exe (the supposed command line version of process explorer) does not return anything. I was hoping that someone might be able to tell me how I was using handles incorrectly, or if there was a better tool for this.

Process Explorer - it has found my dll ComHelper.dll ProcessExplorer_working

Handles via command line - it has not found my dll ComHelper.dll HandlesCommandLine_not_working

-- Edit -- This is the output of handles when I point it at w3wp while running as Admin HandlesSearchingForW3WP

The Handles utility tells you about allocated handles. A DLL dependency doesn't consume a handle. — Hans Passant, May 13 '15 at 22:28

banal · Accepted Answer · 2015-05-13T21:10:55.783

3

I would suspect you are running into access issues. Are you running Handle from an elevated command prompt ? Are you able to get any output covering handles in w3wp.exe (by using the pid of the process in handle.exe command line) ?

Looking at the handle enum output of w3wp.exe it seems,

listdll.exe -d ComHelper.dll

may be what you are looking for. Handle seems to be focused on files opened not dlls loaded. listdll is a tool that can be downloaded from sysinternals.

edited May 13 '15 at 21:10

answered May 13 '15 at 18:01

banal

98
1
8

It's a possibility, but I'm not sure how I would go about diagnosing that. The command prompt that I'm running above does have elevated permissions due to the fact that I'm running it as admin. As for the output of w3wp, I'll go ahead and get that added to my question. – user1079703 May 13 '15 at 19:34

score 0 · Answer 2 · answered May 13 '15 at 21:56

Alright so 32 bitness did matter. I ended up having to resort to powershell as opposed to trying to use handles. The code for finding a PID that has a lock on your file is scattered around the internet, but here's the link: http://blogs.technet.com/b/heyscriptingguy/archive/2013/12/01/weekend-scripter-determine-process-that-locks-a-file.aspx (it's marv the robot's answer at the bottom)

For the record, this is what was suggested

$lockedFile="C:\Windows\System32\acproxy.dll"
$isLocked = $false
Get-Process | foreach{
    $processVar = $_;$_.Modules | foreach{
    if($_.FileName -eq $lockedFile){
        $isLocked = $true
        $processVar.Name + " PID:" + $processVar.id
        }
    }
}

This is what I had translated it into with my powershell noobishness

$lockedFile = "E:\Components\___ComHelper.dll"
$list = Get-Process
foreach ($process in $list)
{
    foreach ($module in $process.Modules)
    {
        if ($module.FileName -ne $lockedFile) { continue }

        $process.Name + " PID:" + $process.Id
    }
}

Why isn't handles.exe discovering my DLL while ProcessExplorer can?

2 Answers2