WMI - App Store Apps

Started by JTaylor, September 04, 2020, 06:27:09 PM

Previous topic - Next topic

JTaylor

Can anyone tell me if I am doing something wrong.   All the MS Docs and other examples indicate that the following should work but no luck.   Just tells me that the obj.Name doesn't exist.

Code (winbatch) Select



strComputer = "."
objWMIService = GetObject("winmgmts:\\" : strComputer : "\root\cimv2")
apps = objWMIService.ExecQuery ("Select * from Win32_InstalledStoreProgram ")
list = ""

ForEach obj in apps
; Message("Name: " , obj.Name)
  list =  obj.Name
; list =  list:obj.Name:@TAB:obj.Version:@CRLF
Next

clipput(list)
message("HEY",list)



td

Just speculating but it might be that you don't have any Windows Store apps. I get one app when I run your script on my system - "Microsoft.WindowsMaps".  I guess I missed it when I de-spywared my system. It could also be a Windows 10 feature version problem or a corrupt WMI MOF file or DLL. It is interesting that the Debian Linux command shell I did download from the Windows Store does not show up.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Jim,


I ran your script - displayed over 50 items. Changed one line to


Code (WINBATCH) Select

list =  list:obj.Name:@LF



When run unchanged - got Microsoft.YourPhone

td

Good point and you are correct.  I overlooked that Jim didn't use a compound assignment operator ':=" when building the list.

Code (winbatch) Select
  list :=  obj.Name:@lf


However,  it still leaves the question, why did Jim get the error?
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

Yeah...I commented out building the entire list to see if I could just get one response.  Thanks for the reminder on the compound operator.  Had completely forgotten about that one.   

I have Movies & TV which I *think* is an App.   At least it shows in the Store.

The error was odd in that if there was nothing in the list I would have thought it would never have gotten to that point anyway.


Jim

stanl

I slightly modified the script to output a base csv that could be used as a map with suggestion to use the base to check for existing or new entries. Attached a base for reference
Code (WINBATCH) Select


strComputer = "."
cFile = dirscript():"StoredApps.csv"
objWMIService = GetObject("winmgmts:\\" : strComputer : "\root\cimv2")
apps = objWMIService.ExecQuery ("Select * from Win32_InstalledStoreProgram")
list = ""
n=1
ForEach obj in apps
  list := obj.Name:",":n:@CRLF
  n=n+1
Next
FilePut(cFile,list)
If FileExist(cFile) Then Message("Stored App CSV Created",cFile)
Exit
;with base lookup can then use
;map = MapFileGetCSV(cFile)
;run the WMI  ForEach obj in apps
;If ! MapKeyExist(map,obj.Name) would find app not in your base list



td

Quote from: JTaylor on September 05, 2020, 07:04:41 PM

The error was odd in that if there was nothing in the list I would have thought it would never have gotten to that point anyway.


Again just speculation but sometimes enumerators will return a VT_EMPTY variant or just "empty" in ObjectTypeGet speak when the enumeration does not hold values.  Since a VT_EMPTY variant isn't an object, attempting to call a property will, of course, fail miserably.

But this still doesn't explain why you have an empty list in the first place.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

I am out of ideas.   I went and installed "MS To Do" from the store just to make sure I wasn't assuming too much.    This isn't super critical now as the pressing need has passed but would be nice to know why it fails in case the need arises again but running out of ideas on how to figure that out.   Thanks all.


Jim

stanl

If you modify your script to look in Win32_InstalledWin32Program - does that give any problems?

td

Likely already thought of but it might be a corrupt WMI repository problem.  The  Winmgmt command line tool is still around on Windows 10 so you might consider giving it a try.

A link to an old support thread on the subject:

https://social.technet.microsoft.com/Forums/windows/en-US/8ed26d46-9994-4052-a307-5b071805aea8/wmi-corrupt-how-to-reinstallrepair
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Quote from: td on September 07, 2020, 08:26:46 AM
Likely already thought of but it might be a corrupt WMI repository problem. 


Yeah, reason I asked about Win32_InstalledWin32Program was one of the threads I wandered into mentioned that if there were issues with that then possibly WMI corruption.

JTaylor

Same problem with  Win32_InstalledWin32Program.    Win32_Products (?)  works fine.

Ran the WMI reset and replace but still the same problem.   Also ran the sfc /scannow.   Everything reported back as fine.

Jim

td

It was certainly worth checking even if it didn't help.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Plan-B: look at



HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall


and check for aeinv.mof -which may be corrupt or missing.

JTaylor

Agreed.

Quote from: td on September 07, 2020, 10:41:58 PM
It was certainly worth checking even if it didn't help.

JTaylor


Will give this a go later today when I return.  Thanks.

Jim

Quote from: stanl on September 08, 2020, 02:45:47 AM
Plan-B: look at



HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall


and check for aeinv.mof -which may be corrupt or missing.

stanl

Of course, Plan-B involves iterating DisplayName for each GUID in the registry entries. Maybe it has been done before and there is code out there. We never got to the Win10 version affecting things. I currently have the 2004 [April 2020 release]. I mentioned in an earlier thread how after it was installed and Edge was pushed, all of my scripting default apps were changed to NotePad++ which compromised some Office scripts.


Anyway... here is hoping your WMI is not MIA

td

WMI MOF files are stored in <system drive>:\windows\System32\wbem.  The Winmgmt should have fixed any problems relating to corruptions but a missing MOF which this problem kinda looks like is another question.  I guess Winmgmt's ability to restore a missing MOF file would depend on the reason for it being missing in the first place.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

aeinv.mof is present and shows Win32_InstalledStoreProgram. 

I tried wbemtest and it shows the Classes as well.

I tried directly in powershell and it responds with:

PS C:\Users\jtaylor> Get-WmiObject -Class Win32_InstalledStoreProgram
Get-WmiObject : Access denied
At line:1 char:1
+ Get-WmiObject -Class Win32_InstalledStoreProgram
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Get-WmiObject], ManagementException
    + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand


PS C:\Users\jtaylor> gwmi Win32_InstalledStoreProgram | select *
gwmi : Access denied
At line:1 char:1
+ gwmi Win32_InstalledStoreProgram | select *
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Get-WmiObject], ManagementException
    + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand

Oh well.   Don't want to waste more of anyone's time.    As mentioned, need has passed but wanted to solve the puzzle.

Jim

td

Ah, the ever-present permission problem.  My gut reaction to your original post was that it was a permission issue but I seem to always fall back on that one...
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

So how does one obtain this Permission, of which you speak?   

I would think running as administrator would do it but same results.   I am quite ignorant of WMI though so maybe there is something else???

Jim

td

I assumed you were executing your script as an elevated admin so I decided to dismissed my gut feeling but there are subtleties to WMI permissions. I believe this problem has come up before. I can't answer your question directly because I don't recall the details. But here is a link to an MSFT article that may (or may not) offer some clues:

https://docs.microsoft.com/en-us/windows/win32/wmisdk/access-to-wmi-namespaces
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

I did...I thought.   Thrown off a bit because Win32_Product worked fine just running the WBT script.

I just found a different script and if I compile it and then run it as Admin it works.  The one I was using still doesn't work for Win32_InstalledStoreProgram.

Thanks again and sorry for wasted time.

Jim

td

The classes you mention are, I believe, in different namespaces or at least in different MOF files.  It is certainly possible that MSFT allows different security settings for different namespaces or MOF files.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

So it would appear  :)

Thanks again.

Jim

td

Also, UWP or Windows Store, or whatever apps have their own group policy settings separate from Win32 apps so that could influence your ability to enumerate them.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

stanl

Quote from: td on September 09, 2020, 05:28:19 PM
The classes you mention are, I believe, in different namespaces or at least in different MOF files.  It is certainly possible that MSFT allows different security settings for different namespaces or MOF files.


Here is a quick way to inventory WMI NameSpaces:
Code (WINBATCH) Select


strComputer = "."
cFile = dirscript():"NameSpace.csv"
objWMIService = GetObject("winmgmts:\\" : strComputer : "\root")
apps = objWMIService.ExecQuery ("Select * from __Namespace")
list = "WMI_NameSpace":@CRLF
ForEach obj in apps
  list := "\root\":obj.Name:@CRLF
Next
FilePut(cFile,list)
If FileExist(cFile) Then Message("WMI Namespace CSV Created",cFile)
Exit





EDIT:  and here is a snippet to obtain classes from separate Namespace
Code (WINBATCH) Select


strComputer = "."
strNameSpace = "\root\SecurityCenter2"
substr = "Product"
cFile = dirscript():"NameSpaceClasses.txt"
usesub = 1
fileout = 0
oLocator = CreateObject("WbemScripting.SWbemLocator")
objSWbemServices= oLocator.ConnectServer(strComputer,strNameSpace)
oClasses = objSWbemServices.SubclassesOf()
list = strNameSpace:":Classes":@CRLF
ForEach class in oClasses
  c = class.Path_.Path
  c = StrSub(c,Strindex(c,":",0,@FWDSCAN)+1,-1)
  If usesub   
     If StrIndexNC(c,substr,0,@FWDSCAN)
        list := c:@CRLF
     Endif
  Else
     list := c:@CRLF
  Endif
Next


If fileout
   FilePut(cFile,list)
   If FileExist(cFile) Then Message("NameSpaceClasses Created",cFile)
Else
   Message("",list)
Endif
Exit


:WBERRORHANDLER
oWMI=0
wberroradditionalinfo = wberrorarray[6]
lasterr = wberrorarray[0]
handlerline = wberrorarray[1]
textstring = wberrorarray[5]
linenumber = wberrorarray[8]
errmsg = "Error: ":lasterr:@LF:textstring:@LF:"Line (":linenumber:")":@LF:wberroradditionalinfo
Message("Error",errmsg)
Exit



JTaylor


td

Happened to be doing some testing on various systems so I threw in a short script that uses the Win32_InstalledStoreProgram class on all systems with versions of Windows that support UWP apps.  The thinking being that if it failed it wouldn't be to difficult to identify a key difference in the system that failed. But no joy, it worked on all systems.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

JTaylor

Appreciate the follow-up.  A large part of the issue is obviously my ignorance.  I just assumed that since I had used numerous other WMI scripts that they all pretty much worked the same.  Hadn't run into one yet where I had to compile and then run as administrator to get it to work.   Guessing that would be problematic to use in a normal app, now that I think about it.

jim