Summary: Ed Wilson, Microsoft Scripting Guy, talks about parsing the DISM log with Windows PowerShell.
Microsoft Scripting Guy, Ed Wilson, is here. One of the things I like to do on weekends is mess around. So I was intrigued when I found a DISM command that would supposedly export file associations (see DISM Default Application Association Servicing Command-Line Options). I thought, "Cool."
Unfortunately, I was not able to find a “PowerShell way" of doing it, but then, hey, the cool thing about a command-line environment is that it makes command-line tools really easy-to-use. So I gave it a shot...
Again, and again, and again.
But dudes and dudettes, it didn’t work.
Note: It might be that command simply doesn't work right in Windows 10, or may be there is an issue running it in Windows PowerShell, or maybe I just didn’t get the syntax right. That is one of the things I love about Windows PowerShell—it is really easy to get the syntax correct. And one of the things I hate about old-fashioned command utilities is that it is really hard to get the syntax correct.
Anyway, the error message told me that it had logged results to a DISM.Log in my Windows folder. I thought, "Cool. I will take a look at it."
Twenty seconds later, the 11,000 lines finished filling my Windows PowerShell console. Wrong move!
Get the end of the file
One thing I did notice is that the DISM.log is written in chronological order. This means that the end of the file will have the most important information. Luckily, Get-Content has a –Tail switch that I can use. The following command gets the last 15 lines from the file:
Get-Content C:\windows\Logs\DISM\dism.log -tail 15
Now that I know where the data resides, I need to do two things: expand my search and store the results in a variable. I type the following two commands:
$a = get-content C:\windows\Logs\DISM\dism.log -tail 200
$a[0]
The first command gets the last 200 lines from the DISM.Log file and stores the results into a variable. The second command retrieves the first line in my variable. This is shown here:
PS C:\> $a[0]
2015-09-24 13:29:52, Info DISM DISM Provider Store: PID=6328 TID=
4040 Found the OSServices. Waiting to finalize it until all other providers are unloaded. - CDISMProviderStore::Final_OnDisconnect
I can now change the amount of information I want, and easily look to see how far back I went. In fact, as you can see here, it takes less than a second to look back 500 lines:
PS C:\> $a = get-content C:\windows\Logs\DISM\dism.log -tail 500
PS C:\> $a[0]
2015-09-24 13:29:11, Info DISM DISM Provider Store: PID=5272 TID=
9552 Connecting to the provider located at C:\Users\mredw\AppData\Local\Temp\EE97F26
7-BE60-4FB7-958B-D7D073FA94D0\SmiProvider.dll. - CDISMProviderStore::Internal_LoadPrOvider
I need to pay attention to the time stamps. Here, I see that I am 41 seconds earlier, and that it might possibly be from a different DISM session. When I have the chunk of data I want to analyze, I can easily pipe the variable to Select-String and try to see what failed:
$a | Select-String "fail"
The output is shown in the following image:
I look through the errors and see Export User Associations from the Registry fails with hr:0x80070003, and before that, Loading a provider fails with hr:0x8007007e.
I know the hr:0x8007007e error usually means Cannot connect to provider, Provider not found, or even Path not found. Also the error hr:0x80004002 is usually something like No such interface.
Not finding the provider and no interface lead me to believe that the way cool DISM command I found may simply not work in Windows 10. Of course, I could be wrong. I do know that the old-fashioned ASSOC command that I used to use also appears to be gone. All that would make sense, I guess.
Anyway, the point is that using Windows PowerShell to parse through text files can be really easy by using Select-String and Get-Content.
Hope you have an awesome day.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy