I want to programmatically get a list of all installed KBs. This could be python code, WinAPI (which I will call from python), running another process and parsing its output, etc. What interests me are security updates, I don't care whether or not other updates are returned or not. However, I want updates for software as well, not just for Windows - anything that shows up in the control panel's "Installed Updates" window.
It's also important that this code will run on all versions of windows, not just a single version (I don't mind having an if-else in the code, with different behavior for different Windows versions - it's just important that eventually it works).
I tried wmic qfe, systeminfo and PowerShell's get-hotfix, all of which return only OS updates.
I have a Windows 10 myself, and I couldn't find a single place in the registry or in the file system where all KBs are listed together. Couldn't make sense of Procmon's output (after recording opening "Installed Updates") either - too large and not focused enough. It seems like different updates are listed in different places, but nothing I could easily understand how to extend/generalize.
EDIT:
I found this code: https://codereview.stackexchange.com/questions/135648/find-installed-and-available-windows-updates
I tried running it on my computer, and it found some KBs that didn't appear neither in the commandline commands I ran, nor in "Installed Updates". On the other hand, there are also KBs that don't appear there but do appear in the other locations..
Thanks!
The problem with qfe is that newer Windows versions have updates for componentes which aren't CBS related, hence wmic path Win32_QuickFixEngineering will not show them.
The trick is to use a COMObject to the updater system.
I've written a small package that does the job, and checks for updates via COM, WMI and registry.
Talking to windows update via COM gives the most information.
WMI gives some information, and registry of course only gives the KB and install date.
Install with
pip install windows_tools.updates
Use with
from windows_tools.updates import get_windows_updates
for update in get_windows_updates(filter_duplicates=True):
print(update)
The duplicate filter is enabled because of AV definition updates that show alot.
Related
First:
I know there are other questions that ask similar/the same thing, I have looked at them tried all of them but no solution has helped.
The problem:
We use Epson Iprojection (downloaded from here: https://www.epson.co.nz/products/projectors/software/) However I can not find a way to get an MSI out of it (I am starting to think there is no MSI bundled in the .exe), and I can not seem to install it through CMD on computer start using AD. Any help will be greatly appreciated.
Vague Answer: Let me try to formulate an answer out of those messy comments above. I only briefly tested this software, it might not deploy as badly as expressed. Remember that this is a generic answer for whoever would find this in the future, and not for OP per-se (there is no real answer in here).
Due Diligence: I always try to consult package tip databases if I have problems with a package. Somebody, somewhere will have seen the same problem (eventually).
Silent Installation: Silent installation of legacy setups is usually possible (not always), but never really reliable. For Installshield it involves recording answer files (setup.iss) that record dialog answers. However, unknown dialogs can show up suddenly on some systems (low disk space, reboot prompts, unexpected lock or application in-use warnings, unexpected service running warnings,etc...) and hence halt the install unexpectedly as the response file has no recorded value for the dialog in question. This particular Epson setup also has an unfortunate reboot requirement on uninstall that is hard to deal with for large scale deployment (spontaneous reboot likely - without warning).
Repackaging: Personally I would try to capture the install using a repackaging tool. Most of these are expensive, but can output MSI, MSIX or other deployment package types. Repackaging fails when the package contains complex, custom logic that - for example - create dynamic content (ciphers, unique GUIDs, etc...) and in a number of very specific technical cases.
Contact Vendor: If you capture an MSI that doesn't work, why not try to send it back to the vendor with some comments on how hard this software is to deploy and maybe mention the major benefits of MSI? I would tell them you have to ditch the whole software from your network if they can't deliver a deployment solution that works. Time is of the essence. "Some solutions are only free if your time is worthless" (quote from Joel Spolsky himself - slightly out of context, but the same issue: we need solutions that work in a timely fashion).
Note: I once had to compile a special setup to deal with a client's
deployment problem that was our fault. Deployment problems need fixing at a standardization level. Standards!
Buried within the single-exe download is iProjection_inst.exe, some sort of wrapper that prompts for language selection, and doesn't seem to have a standard "non-interactive" mode.
Inside this is instData\Setup.exe, a vintage "full screen" InstallShield installer with external ini / cab files.
Running this with Setup.exe /? doesn't give any command line arguments, as it would for a modern InstallShield setup.exe.
Although it supports recording an answer file via Setup.exe /r, when I try to replay the answer file with Setup.exe /s it seems to still prompt for EULA, and then fails to install.
So this is really a design flaw in the innermost installer to do with the dialog sequence.
Assuming Epson won't fix it and repackaging is too hard, a hacky alternative is to use Powershell to automate the UI of instData\Setup.exe once the "Welcome" screen is showing, but I don't think this will work running as an AD script.
$wshell = New-Object -ComObject wscript.shell
$aName = "Epson iProjection Setup"
function Next() {
if ($wshell.AppActivate($aName)) {
$wshell.SendKeys(' ');
start-sleep 1;
}
}
function AcceptEula() {
if ($wshell.AppActivate($aName)) {
$wshell.SendKeys("{TAB}");
$wshell.SendKeys("{TAB}");
$wshell.SendKeys(' ');
start-sleep 1;
}
}
Next; AcceptEula; AcceptEula; start-sleep 20; Next;
I know this is an old thread but it looks like it may be easy now. The latest 2.41 from here
http://www.downloads.epson.com.au/DownloadFile.asp?filename=iProV2411Win%5FWEB%2Eexe&path=Drivers
seems to have an MSI in it. Just jump into the %temp% folder and organize by date so you can see the latest files. Run the installer and a new folder named with a GUID should show up, in my case {27CDEEE8-B6F2-45a7-A48E-696862573D9B}.
Under this folder there is a series of InstData folders like InstDataX64 where you can find an MSI.
So i recently got myself into a sticky situation, it seems like windows 'forgot' about a program I had installed (some drives changed letters / not really sure what happened).. I could find files that it created, but in 'Programs' and 'Add/Remove Programs' it is not there.
Also, when I use the 'programs' installer, it says it cant install because it exists already (to some extent), and I can un-install because windows doesn't know it exists.
BUT! I have an executable of the 'program' that works.
So I am wondering what the difference is between an executable, and what windows considers to be, and keeps track of, a 'program'.
This is definitely the kind of program that would show up in 'add/remove programs', as I have several other very similar ones from the same company that show up there, and I know it used to show up there.
I am not looking for wikipedia answers, I am interested in what exactly a 'program' is. What are the necessary pieces that make up a 'program' as far as windows is concerned?
For a program to show up in "add/remove programs", it needs to be installed. Typically, this is done through an installer that takes care of registering the program with windows and modifies the environment so that the program functions properly.
It may modify the registry to store user preferences for example...
When you have just an executable, it's not necessarily installed. It may be standalone.
Some programs don't absolutely need to be installed even if it's the canonical way to add a program in the Windows system. That's why it may work.
Another executable may fail because it relies on modifying the state of the system to work properly.
I hope it helps :)
Well, I'm using Visual C++ 2010 Express and ResEdit
for my midi sequencer's SETUP app.
Win32 API, no MFC, some custom window and control classes and such.
Now that I got Windows 7, my dang SETUP program is broke.
Windows gives me the ole "Did this app install correctly??" thingy.
Which implies that SOMEthing is wrong with my installer.
I'm tryin' to figure out what that might be...
I've seen these 2 SO threads:
"This program might not have installed correctly"
"This program might not have installed correctly" message in Windows 7 RC
Which have lead me to these places:
http://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb756937.aspx
http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3
http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-rules-on-you.aspx
http://community.flexerasoftware.com/archive/index.php?t-189007.html
Only registry entries I use are the standard uninstall spot and
associations for filetypes.
SETUP writes a dat.cfg file in program files\pianocheater dir
that points to where all the app's data is. (just a text file with a path in it)
(And an etc.cfg for a temp dir within that data dir to use.)
So I'm only READING from programfiles\pianocheater post SETUP.
Can anybody think of why Windows wouldn't like the install?
Source code is at http://shazware.com/_etc/SETUP_PIANOCHEATER.cpp
It uses my library of window, control classes similar in spirit to mfc.
I could send useful parts of it, too.
It's not toooo bad for a setup app.
Should be pretty ledgible for a win32 guy/gal.
I could uuuuuse some he'p...:/
Oh yeah, I should point out that Go() is the entry point instead of main().
The DBG()s just do OutputDebugString() and seem to all run just fine.
TStr is just a big char[MAX_PATH] (and I don't do unicode)
And the trick PROBably is that I'm on win7 64 bit, but this is a 32 bit app.
I'm pretty sure I'm using the registry correctly for assoc's and uninstall spot, though.
So is THE thing I SHOULD do the manifest xml thing?
Or is there a more correct way to do things?
thanks much,
...Steve
First off, check whether that message is a false positive or not. The message you're seeing is designed to use heuristics (which can be wrong!) to determine if an installer failed due to Windows Vista/7 compatibility issues. If your installer is in fact compatible with Windows 7/Vista, then all you need to do is add a manifest declaring itself compatible. You'll also want to add a requestedExecutionLevel entry to your manifest as well to request elevation.
If your installer is in fact failing, of course, then you ought to fix that first.
Finally, if the error is showing up because a launcher executable exits early or something like that, consider suppressing installer detection by adding the appropriate manifest entries to the launcher as well (you may be able to use a requestedExecutionLevel of asInvoker if the launcher doesn't need administrative access; the presence of a requestedExecutionLevel manifest entry should suppress installer detection). Note that you should make sure you use ShellExecute to invoke your main installer process, not CreateProcess, or UAC may not elevate the child process.
Windows 7 is caching some of the COM class information. Older OSs didn't do this. After the OS looks up theHKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value, it caches the value, and doesn't look it up again.
When we update our software, we place the new updates in a different directory, and then update the HKCU\Software\Classes\CLSID\{GUID}\LocalServer32 value to reflect the new path. The next time the software runs, it will use the latest files if running under older Windows OSs. However, on Windows 7, it will continue to use the older file, until the OS is rebooted.
I ran process monitor, and discovered that under Windows 7, it never reads the registry key again, after the first read. On older OSs, it reads that key every time.
My question is: Is there any way to force Windows 7 to re-read the LocalServer32 information from the HKCU hive each time a new out of proc COM object is created?
I have only been able to solve this problem by...
1: Stopping the Process
2: explicitly unregistering using regsvr32 the library ( or exename /unregserver)
3: Registering the new component
4: Starting the process back up.
I would suspect that it is the Un Reg part that is failing for you. If you are just changing the registry key directly then you should call RegSvr32 /u instead.
Also make sure the new directory location is the current directory when you call RegSvr32.
Note that I have always stopped the process and then unregistered, this is probably a significant detail.
As this is a top result in Google for this narrow-ish problem, I thought it would be valuable to add my troubleshooting outcome for this problem.
I found this response on SO: C# : How to change windows registry and take effect immediately
And linked solution from that answer: Registry Watcher C#
Both of which seem viable options for managing changed keys without forcing a reboot. For us (like the OP) this was when installing updates. For us (possibly unlike the OP) this is infrequent and we decided the effort to implement and test a fix as described was outweighed by the simple solution of requiring a reboot: a process Windows users have come to expect with installing software anyway.
Our software is not ever officially installed on Windows, and currently has an update model like this:
Connect to Internet
Click an Update Button
Connect to server-side program
Server-side program creates an md5 hash list of all the files in
the server program directory.
Client-side program creates an md5 hash list of all the files in
the client program directory.
A comparison is done to see if a file needs updated, removed from, or added
to the client's machine, and it does so until complete.
Well, I would like to move to a model I see used more frequently these days where the software is officially installed and something like this happens:
When an internet connection is detected, the program will automatically query the
server to see if there is an updated installation package.
If so, ask the user if they would like to download the new install.
If no, do nothing, if yes, download new install.
Programatically uninstall the old program and start the install of the
new package.
The part I need advice on is number 4 above. What is the best way to programmatically uninstall the old program and start the installation of the new program, while running the original program. I assume there must be some intermediary program that does all the work (shutting down the current program, running it's uninstaller, then starting up the new installer) Is there a better way? I just want to move to a model where we update in full installs and not just files - this will allow us to version our software easier and keep self-contained installations to revert to at any point.
Thanks for your advice!
EDIT: Related question - what's the easiest way to find the install UUID for a particular install?
The way I did it was to have a separate program (let's call it StartUp.exe) that checked for updates and then loaded the real software (let's call that Program.exe). StartUp.exe had the same icon as Program.exe and was the executable that was pointed to by the desktop shortcuts and menu items, using the same name as Program.exe.
So the sequence went something like this:
User double-clicks desktop shortcut or menu item that looks like Program.exe and is called the same name but is actually StartUp.exe
StartUp.exe runs and checks if there are any updates
If there are updates, it simply copies then across (we built a nice system with progress bars but you could simply copy the new files over the old files)
StartUp.exe then runs Program.exe
StartUp.exe then exits
This has the advantage that none of your program files are locked because the loader program is actually a different program. The user is none the wiser because they run a program that looks like and is called the same as the program they want to run and the end result is the program they want does run and is guaranteed to be the most up to date version.
Doing it with an update button would be more complex but we needed to force the most recent version of the program to be the one running (due to database differences between versions) so forcing update on startup worked for us.
I believe the way to do it these days is to use ClickOnce deployment but I've never tried that - it wasn't available when I wrote my system and this method was simple and worked well.