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.
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)
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.
Jim,
I ran your script - displayed over 50 items. Changed one line to
list = list:obj.Name:@LF
When run unchanged - got Microsoft.YourPhone
Good point and you are correct. I overlooked that Jim didn't use a compound assignment operator ':=" when building the list.
list := obj.Name:@lf
However, it still leaves the question, why did Jim get the error?
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
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
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
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.
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
If you modify your script to look in Win32_InstalledWin32Program - does that give any problems?
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 (https://social.technet.microsoft.com/Forums/windows/en-US/8ed26d46-9994-4052-a307-5b071805aea8/wmi-corrupt-how-to-reinstallrepair)
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.
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
It was certainly worth checking even if it didn't help.
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.
Agreed.
Quote from: td on September 07, 2020, 10:41:58 PM
It was certainly worth checking even if it didn't help.
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.
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
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.
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
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...
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
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 (https://docs.microsoft.com/en-us/windows/win32/wmisdk/access-to-wmi-namespaces)
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
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.
So it would appear :)
Thanks again.
Jim
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.
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:
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
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
Thanks.
Jim
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.
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