Diagnose App Failures with ProcMon + "Dependencies" Tool (Real Examples)

Hello, my name is Lowell Vanderpool and this channel is dedicated to IT students, IT professionals, and anyone who enjoys learning technical subjects. We are looking at Rokron Process Monitor and trying to help IT professionals use Process Monitor to solve the six or seven major problems found typically in applications. We're not trying to debug applications that we're writing code on. In the case of this video, we're going to be looking at missing dependencies, files that are missing. That is something that we definitely can do if we know what the file is. If we know how to find a copy of that missing file, we can restore that missing file to its proper path and location and voila, the application works. Well that's definitely something IT pros and IT admins can do. In order to troubleshoot dependencies, we first have to understand what they are. So this is my favorite tool as an IT pro and that's Process Explorer. You can see all the processes in user mode that are running right now. I can scroll through here and I can see all my processes. I can see my parent-child relationship. I can see so much information about the operating system, services, and applications that are running that just no other tool gives me that view. Come down here to Explorer. Explorer is a great starting point for me as I troubleshoot applications in the user space because that is where the shell for Windows begins. So Explorer.exe is actually this graphical desktop that I'm running right now. It is what is known as the shell for Windows. Everything below it has been launched by the user. Notice the color is all a purple or blue. All these processes that are below Explorer.exe have been launched by the user who is logged on. There is a process called PortableApps.com and I'm going to go ahead and bring it up here so you can see it. And this is nothing but portable apps. If you've been around any of my videos, you know that I love portable apps. All of Microsoft's system internals are portable apps. They don't install. They don't edit your registry. They simply run with a runtime executable. All of these utilities that you're seeing in this graphical user interface are all portable apps. So I'm going to run Cam Studio. Double-click it. This is a great utility. It allows you to record your screen content in video or simply capture it as graphic elements. If you look below, down here is Cam Studio and you can see it as I highlight it right there. And you can see the process. This is indicating the process that represents CamStudioPortable.exe. And below it is a child process called Recorder.exe. Now I'm going to click on CamStudioPortable.exe, come up here, and I'm going to show the lower pane. What it does is allows me to look at the handles concerning that process, the DLLs, which these are the dependency. And then I can also look at threads for that particular process. I'm going to come back here to DLLs. And if you'll notice, these are the names of DLLs. All of these files that I'm scrolling through are files that are loaded within the process, CamStudioPortable.exe, and are required in order for this application to function. In other words, CamStudioPortable is dependent on all of these files functioning and working. So if one is missing, it's going to generate an error message, it's going to lock up and freeze, or in the case of our demonstrations, it's just going to launch and terminate. It's going to launch and just exit out because a file that it's dependent upon, which is what we call dependencies, didn't exist or is missing or not on the right path or something. This is a very common problem with applications. And you can look, let me scroll up here, CamStudioPortable.exe has many files that it's dependent on to function. So if any of these files are missing or in the wrong place, it's not allowing the process, CamStudioPortable.exe, to pull these files into its process container and run them. It's missing dependencies. First of all, we're going to understand what are dependencies. And then second of all, we're going to understand how to identify and discover missing dependencies. So let's first look at what are these dependencies. Again, in our example, you can see I've got CamStudioPortable.exe. That's my example application. In this case, it's a process. Also, an application and a process can sometimes be synonymous. And it's got a child process called Recorder.exe. Each of them have files inside that process. Over here, I've got my lower pane displayed, and I've clicked on the DLL tab. And it is showing me a long list of DLLs that are running inside this process. Notice their path. Most of these are syswow64. That tells me right away this is a 32-bit application because it's using DLLs found in the wow64 folder within Windows. We know that wow64 are the application DLLs for 32-bit applications. I'm going to select Recorder.exe, and I'm going to come down and look at the same thing. I'm going to click on the DLL tab in the lower pane. And this time, I'm going to look at the paths for all those DLLs on the left-hand side. I want to look at any path that points to where this application actually stores its files. Notice a lot of them are system32 or syswow64. That means they're 32-bit DLLs. It also has system32 DLLs, which are system DLLs for the operating system. And here I've clicked on camhook.dll, and I can see its path, where it's actually stored, is where the application is stored. So I know that this DLL was designed by CAM Studio developers, and it is used for a specific use within this application. Here's another example. I've got an mfc100.dll, and if I look at the location of that DLL, it's in the location where CAM Studio is actually located on the hard drive. I know that DLL is very specific to this application. In other words, the developers who wrote CAM Studio wrote that DLL. All of these other DLLs that are part of the dependency group of files needed to run this application were not written by CAM Studio. They're written by Microsoft. They are Microsoft DLLs. Now, I've pulled up Explorer so that you can see it, and you can see I'm in Android. We have a subdirectory called Portable Apps, and then another subdirectory called Portable Apps, CAM Studio Portable, and that's where I'm at right now. You can see I'm in that path, and then it goes to App, and I'm going to go ahead and go to that subdirectory. Then it goes to CAM Studio. I'm going to go ahead and go to that directory. You can see I'm just walking through the path, and I'm going to try to find this mfc100.dll. I found mfc100.dll. Now, what I'm going to do is simply rename it. So, I'm going to come into more options, rename that file. I could have done this a couple of different ways, and I'm going to just type in test so that I'll know how to go back and find that file and change it back. Dash test is all the modification I made to that file, and now when this application tries to find the properly named file, it's not, and it's going to have problems. That's a missing DLL or a missing dependent. We've created a problem within the application. We're going to create a missing dependency, a DLL that is not going to be found and not loaded. We don't know exactly what the behavior of this particular application. The application could generate an error message. It could open and then terminate. It could freeze. It could lock up. You get it. But this is a problem that if we could discover what the problem is, in this case, a missing file, we could possibly solve this problem. We're not developers. We're IT professionals or admins. But there are lots of application errors that we can fix. Missing file, file not found, a missing file. Many times we can go find a copy of that file, put it in its proper location, and we're back in a running application. Let's launch CAM Studio again and watch in Process Explorer. It should show up somewhere in here, and let's see what happens. Double click. It launches, and you can see down here it turns green and then turns red, and it's gone. So here it launched. The process turned green. Let's do it again. I'm going to run CAM Studio. And notice CAM Studio Portable Apps.exe turns green. It's launching that application, and then it turns red. That process terminates. Something went wrong. That's a very common problem. Now, I could have got error messages. I could have got the application locked up. The application could have ran perfectly until I executed another function, and then an error message came up. So there's no cookie-cutter response with a missing dependency. But something will not work right. Each time we do these ProcMon Part 1, Part 2, Part 3, I also want to show you more features and functions within ProcMon or Process Monitor. Today, I want to show you how to save your filters. We saw in our video Part 1 when we were dealing with permissions, how could I save all those filters so that when I want to troubleshoot applications, I don't have to remember the video that Mr. Vanderpool did. I can just go back to the filters related to troubleshooting permission issues and pop them back into my Process Monitor, and I'm ready to troubleshoot. Well, let's take a look at how to build a filter and save that filter for future use. You can see here, I'm already capturing events using Process Monitor. If I want to see it in real-time actually happening on the screen, you can come up to Edit, and I do auto-scroll or Control-A, and you can actually see this is what we call noise. It's capturing all of these events right now. It's overwhelming. There's so much information. Now, that's the power of Process Monitor, but it's actually a disadvantage. Using filters allows us to get rid of what we don't need in order to solve the problem. We can turn off auto-scroll back to Edit, Control-A, and it stops. It's still capturing data because you can come down to the bottom and see that I've already captured almost 9 million events. Another powerful feature that I want to show you in part two is if I'm working with a laptop or a server or anything else where I have limited disk space, I can come up to Options, because I know I'm capturing a lot of data, and I go to History Depth. Here's where I can say I want to create a ring buffer, and I want to limit that buffer size to 100 megabits, 1,000 megabits, whatever you want, or you can say I want to enable a ring buffer that's limited to 10 minutes. Only a limited amount of information is going to be saved, and then it will be overwritten as new data comes in. That way, the data collected on that hard drive is going to be limited, and you're not going to find yourself exceeding the amount of free space and crashing or burning the operating system. Let's begin setting up our filters to capture missing dependencies. We're going to do process name is, and then the image that launches that process. When I say process, we're talking about the application or service that you're troubleshooting. For example, Microsoft Word. The image is WinWord.exe, so we have to know enough about the application to know what is the file that launches that process. Keep in mind that CamStudioPortable.exe was the parent process, and the child process was Recorder.exe. We're going to put both of those in our filter. Next, we're going to do operation is load image. Operation is create file. Remember, create file means you're opening a file. Then, finally, we're going to do result is name not found. We put in the first column. We put in process name. The condition is the value is Recorder.exe. That's one of the images that launches the second child process, and we're going to include it. Then, process name is CamStudioPortable.exe, which was the parent process for the CamStudio. Then, we have operation is load image, and we're going to include that. Operation is create file. Remember, that reads a file or opens a file. Then, result is name not found. We're going to save this. We'll go ahead and apply. Say okay, and I want to save that filter. I'm going to call it my filter, filter depend, whatever name you want to give to your filter. That way, we can reuse that over and over. We'll say yes, override it. Now, we'll go ahead and start the capture. I'm going to go ahead and get my portable apps. I'm going to launch CamStudio. You can see it's capturing the data. Let's go ahead and let's get this out of the way. Let's stop our capture. What we want to do is now look at what we have and see if we can determine what is it trying to tell us. Our results are showing us a lot of name not found. We can see this list of trying to open or read a file. It gives us the path and the file that is trying to open or read. It's saying name not found. That means it couldn't find it in that location. We can see this wow64log.dll. It wasn't here. It's giving us the result that name not found. Let's continue down this list. You'll see and understand the pluses and minuses of using Process Monitor to find missing dependencies. Okay, Mr. Vanderpool, if CamStudioPortable.exe here in the column is trying to open a file, which create file operation, and these are all the files that it is attempting to open, and they're all not found, how in the world are we ever going to find the missing dependency? Good question. First of all, I want your attention on CamStudioPortable.exe and the list of files and paths that are found here by CamStudioPortable.exe. If you'll notice, they're almost all unique. Almost every single line is trying to find a file, tells you what it is and where the path is, and then it says name not found. But notice what happens when we get to Recorder. The first one, notice what happens. We see a DLL in the system32 wow64log.dll that can't be found. That's all we know. And then look, from here on out, it's mfc100.dll. It's looking for that file in this location and it can't find it. Then it looks at the same file in this location, and then in this location, and in this path, and in this path, and in this path, and notice it's the same file name. It's hunting all these different paths to find the same file. Guess what? Bingo! You found the missing dependency. What Windows is doing is following the environmental variable path. It couldn't find it in one location. Now it's looking for another location, and another, and another, and another, and it can't find this file. And it's the same file. Whereas CamStudioPortable.exe, it was almost a unique file every single time. Let's dig into this. This is from my notes. Look what it's saying. You rename a known dependency DLL, which we did. The app fails to start, which it did. And we expect Process Monitor to show us missing dependency. File.dll could not be loaded. But instead, we get this. 30 plus create file or 30 plus load image with name not found. This is exactly what we got. We got a lot of these create file, file not found. What we were expecting is missing dependency. Could not load it. Here it is. We didn't get that. So why does this happen? One, it's called DLL resolution probing. Windows is following the environmental path to try to find these files. The problem is, it may eventually find a file, but we will not see it in our result. So where we saw it not find a file, and then the next line, it was looking for another file, couldn't find that one. We never saw that it found those files. But we assume that it did, because they never showed up again searching for that same file. Unlike recorder.exe, where it began searching for the mfc100.dll, file not found, kept looking for another location, another location, looking for the same file, another, and it just keeps going through the environmental path to try to find this file. That file, it's not finding. If you're familiar with Windows environmental variables, I'm on the system property of Windows 11. I'm going to open up environmental variables, bring this down. This is the path for the user. These are the directories that it will search for user-specific data. Down here is the path for Windows system-related files. And if I open this up, you can see these are the various paths that it will look for to find a file. And in the case of our missing DLL, it's going through each of these locations to find that file. It can't find it. So it keeps looking here and here and here until it gives up. Now keep in mind, when we modified this mfc100.dll, we didn't really know what it would do. In this case, we found out quickly that it really didn't impact camstudioportable.exe. That wasn't the process that it impacted. It impacted the secondary or the child process that was launched by recorder.exe. That child process could not find a dependency at mfc100.dll and it terminated, which terminated the parent. Back to my documentation. You may see multiple create file or load image attempts with name not found. Even for DLLs that were eventually found, the name not found does not necessarily equal a failure. The fact that it never shows up but once meant that it eventually found it. It's when you don't see it found repeatedly over and over and over tells you it's not finding that file. Keep in mind, ProcMon is blind to the loader intent. It doesn't know which DLLs are required by the binary. It just logs file activity, not dependency resolution logic. DLL loading is fast. If a process exits quickly due to failure, which in our case camstudio did, ProcMon may miss or miss sequence the logs or the log is there but it's lost in a pile of noisy entries. Will ProcMon help you find a missing dependency? Yes. You need to know what image. If you'll use these filters that we have already shown you, you can pretty well nail down a missing dependency but you'll have to keep looking till you find the DLL as it's repetitively searched for and the result is file not found. In this case, you can see almost a total of 11 separate subdirectories that it searches for that file and never finds that file. It's a missing dependent. Let's take a look at another problem with an application. Remember, we're not looking at these problems from a developer point of view but from an IT professional, IT admin. We're looking at missing dependencies. Files that that application is dependent upon in order to run and function, it's missing for whatever reason. Take a look at the application as it normally behaves when things are working fine. I'm going to go to a launcher, run Audacity and let that launch and okay it's good. That is its normal behavior and its normal look and feel. Now let's introduce an error or problem, a missing dependency and let's see what happens. So let me exit out and I'm going to choose a file here. It's called lib.audacity-application-logic.dll and I'm just simply going to right mouse click and rename and modify the name of the file so that it will appear as missing. Now let's launch that same utility and see its behavior. Here's my launcher. I'm going to double click Audacity. Notice it seemed to launch and then it just disappeared. Now we don't know for sure when we modify an application like this. I don't know exactly what it's going to do. We're seeing some consistency here where the behavior is that the application launches and then terminates. That doesn't mean that every missing dependency is going to do that. It could generate an error message. It could work perfectly until you have a certain feature or function to run and then you get a problem. So we just don't know. This is a great opportunity for me to introduce a new feature, one that I've mentioned, but now we're going to go take a look at it and why I love this feature in Process Monitor. So I'm going to stop my capture. I'm also going to erase all the data. We're starting with a clean slate and I'm going to go ahead and start the capture this time and I'm going to go to the launcher and launch Audacity. There it is capturing the data and so I can stop the capture. It basically launches and then terminates. I'm going to use a feature of Process Monitor called Process Tree. I'm going to click that icon and pull this Process Tree. This is like a small process explorer within Process Monitor. Let's scroll down and see what happened because it happened very quickly and we really didn't see exactly what was going on. I'm scrolling down until I find launcher. There's explorer.exe. Remember that's my shell. I'm going to come on down. There's my launcher, portableappsplatform.exe and there's audacityportable.exe. Then up below what I didn't see was a child process and I want you to look at lifetime. Look at this green column here called lifetime. I can see that audacityportable.exe started, ran until this point and then terminated. Then right below it I can see where audacity.exe launched and it terminated right away. Then at some point down the road audacityportable.exe also terminated. It happened very fast but I can see clearly now that I'm using this feature in Process Monitor and it's called lifetime. I really can see that launching and terminating. I see that I've got my main process and it's launched by the image audacityportable.exe. Then below it I see a child process called audacity.exe. Let's go fine tune our filter and see if we can see what's going on. I'm going to open our filter and you can see I've added process name is audacityportable.exe and I've included it and then I've also included process name is audacity.exe. We still have our create file. We still have our load image. We still have our name not found. So all the other components of our filter that helps us catch these missing dependencies we've left in there. We've just added the two new processes. I'm going to go okay. I'm going to clear all this data. Go to my eraser. Get rid of all this data. I'm going to go ahead and terminate the process tree. Start my capture and I'm going to go ahead and launch audacity. And we can see it captured this information and now let's take a look at our results. Under audacityportable.exe I can come over and see that almost all of these are unique. Again I'm not too worried about unique creation or opening of a file. But the minute I get to audacity.exe, that's child process, I can see the lib-audacity-application-logic.dll again and again and again and again. We see that common behavior and bingo. I know this is using the environmental variable search order to see if it can find this file and it's not finding it. Although we don't get that exact error message like we didn't find this file, we can see it search through the environmental variables path and it can't find it. It just keeps searching and searching. So our our takeaway from this action is that that's the file that's missing. All right Mr. Vanderpool, what if I'm looking for an application error and I suspect it's a missing dependency and I am using all the things you've showed me and I still can't find it. There is a third-party tool that will show and you can fall back on this tool. Just in case Process Monitor is leading you astray using all the filter techniques that we've shown you, you still can't seem to find the problem. Your gut instinct it is a missing dependency. Let's go look at this other tool. The utility that I'm going to show you is from GitHub and I'm going to have a link to the location on the GitHub site where you can get this application and it's delightful. It's called Dependency and I'm using the 64-bit version. We know that we have two images involved in here, audacityportable.exe, that's the parent, and then audacity.exe. Let's open each image one at a time and let's see what this tool can do to help us. I'm going to open up the first image and I'm going to go back to Audacity Portable and that's the first image and that's the parent process. I'm going to open it up with this utility. If you study this utility, it walks you through all the dependent files needed for this application including both Microsoft and the ones that are developed by Audacity's development team. You can go through and look at all these utilities and you can spend all day in this tool. Now let's go to the second image. I'm going to File, Open. This time I'm going to go to App, Audacity 64 and this is the second, the child process. We're going to go ahead and open that one and voila, look at that. Right away with no searching or hunting, there's that lib-audacity-application-logic.dll and look at that. We could not find this DLL file on the disk anymore. Please fix the problem and refresh the window via F5. So without any massive troubleshooting skills, boom, there's my missing DLL. That's what makes this tool very, very interesting. Now obviously, I'm not showing you all the features and functionality, but you can see how easy it was to use this tool and it just throws the problem right there in your face, easy to see, easy to spot, and you're ready to at least know that is a file that it's dependent upon and it can't find it. Now that everything is working fine, let's run the tools again and see what our process monitor with our established filter shows us. I'm going to first kick off our capturing of data. Notice nothing is showing because our filters are in place. Let's go ahead and launch the CAM Studio and notice it is finding information. Let's go take a look. We see a lot of captured data, both regarding the column that has to do with camstudioportable.exe, almost the same amount of data as before. But look at recorder.exe, a lot of file not found over here in results. What do we notice now that things are back to normal? Well, one, we still get a lot of these create file operations, files and paths, name not found. In our case, we see about the same amount of file not found, files and paths in CAM Studio as before. In record.exe, we still see a lot, but we do not see the same file being looked for and not found in the path of the environmental variables. We see a lot of files that are, quote, not found, but we're never told that they are found. What we do see is they never show up again. They show up one time, except we see a little bit of area right here, this wdmaud.div. We see it's looking for, and notice it never changes the path. It just says it can't find it. I don't know exactly what that means. We're not seeing the behavior of a missing dependency, although we're seeing create file and we're seeing file not found when a deal or a file that's in the dependency list of a process. We would see searching the environmental path to try to find it, the same file name over and over and over in different paths as Windows attempts to search through the system path or the user environmental path to find that file. We don't see that. We see a lot of file not found, but none of the situations that we saw when we actually had a missing DLL. What's the bottom line? ProcMon isn't a super dynamic tool to find missing dependencies. Dependency tool, our x64 version, did a great job and just, bam, just showed us that missing dependency or that missing DLL as it looked at the file system and looked at the recorder.exe manifest file and said, okay, these are the files that I need to pull off the hard drive and this one's gone. That was great. That was very helpful in helping us find a missing dependency. We can use ProcMon to do it, but it's a little bit more challenging.