When launching VSIXInstaller.exe from our application, we're trying to use the ExitCode property on the Process object to determine if the package was successfully installed, but we've found that the exit code is 0 even if the user clicks the 'Cancel' button on the dialog.
I expected that there would be some other code returned in that scenario, similar to what msiexec does.
However, when I searched for documentation about the exit codes VSIXInstaller uses, I don't find anything. I'm looking for something along these lines.
These exit codes come from various inheritors of the Microsoft.VisualStudio.ExtensionManager.ExtensionManagerException class:
1001 ExtensionManager.AlreadyInstalledException
1002 ExtensionManager.NotInstalledException
1003 ExtensionManager.NotPendingDeletionException
1005 ExtensionManager.IdentifierConflictException
1006 ExtensionManager.MissingTargetFrameworkException
1007 ExtensionManager.MissingReferencesException
1008 ExtensionManager.BreaksExistingExtensionsException
1009 ExtensionManager.InstallByMsiException
1010 ExtensionManager.SystemComponentException
1011 ExtensionManager.MissingPackagePartException
1012 ExtensionManager.InvalidExtensionManifestException
1013 ExtensionManager.InvalidExtensionPackageException
1014 ExtensionManager.NestedExtensionInstallException
1015 ExtensionManager.RequiresAdminRightsException
1016 ExtensionManager.ProxyCredentialsRequiredException
1017 ExtensionManager.InvalidPerMachineOperationException
1018 ExtensionManager.ReferenceConstraintException
1019 ExtensionManager.DependencyException
1020 ExtensionManager.InconsistentNestedReferenceIdException
1021 ExtensionManager.UnsupportedProductException
1022 ExtensionManager.DirectoryExistsException
1023 ExtensionManager.FilesInUseException
1024 ExtensionManager.CannotUninstallOrphanedComponentsException
1025 ExtensionManager.CorruptInstanceException
1026 ExtensionManager.RunFromEnginePathLocationException
2001 VSIXInstaller.InvalidCommandLineException
2002 VSIXInstaller.InvalidLicenseException
2003 VSIXInstaller.NoApplicableSKUsException
2004 VSIXInstaller.BlockingProcessesException
2005 VSIXInstaller.UserCancelledException
3001 means any other exception.
P.S. To escape the situation of getting the zero exit-code when a user clicks "Cancel", use silent installation (/quiet flag in the command line) if it is appropriate in your scenario.
Edit: As of Visual Studio 2017 15.7, VSIXInstaller returns the exit code of 2005 if the user cancels the installation.
Related
The setup: An automated test station, built around a Windows 7 PC. The UUT (Unit Under Test) are connected and disconnected often, creating many COM ports.
The Problem: The test is searching for the device at a specific COM port, requiring the user to manually remove the "ghost" com ports.
The question: Since the software is used by several test stations in parallel, at a production floor, I cannot install additional software (e.g. Devcon, part of Windows SDK). Is there a command line option to remove the COM ports?
Based on This blog entry
The only thing that actually worked for me is not the intended solution... But it fit the case at hand:
Created a batch file at C:\windows\system32
The content:
REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter" /v ComDB /t REG_BINARY /d 0206 /f
The actual value of the registry key (0206 in my example) can either be read from that key (use regedit) or calculated from binary:
com8 com7 com6 com5 com4 com3 com2 com1 com16 com15 com14 com13 com12 com11 com10 com9
0 0 0 0 0 0 1 1 0 0 0 0 0 1 1 0
since I wished to keep com1, com2, com10 and com11 - 0000 0011 0000 0110 - which stand for 0206
executing this batch file will remove the unnecessary comports while leaving the one's I intended
*The batch should be at system32 to be executed as elevated (administrator)
*for more details refer to this PDF
Process Explorer has columns for CPU time (down to milliseconds) and CPU Cycles. For WinDbg I am aware of the !runaway command, also !runaway 7 for more details, but it shows CPU time only.
Are the CPU cycles also available somehow in a user mode crash dump?
What I have tried:
I looked at dt nt!_KTHREAD and I see it has a CycleTime property
ntdll!_KTHREAD
+0x000 Header : _DISPATCHER_HEADER
+0x018 CycleTime : Uint8B
I tried to query that property in a !for_each_thread, but WinDbg responds that it's available in kernel mode only.
Why do I want those CPU cycles?
I am working on a training for JetBrains dotTrace. It has an option to count CPU cycles and I'd like to explain where this cycles come from. Above kernel structure and Process Explorer is probably enough, but it would be awesome to see it live or post mortem in a user mode dump. I explain a lot of basics with WinDbg.
Following the implementation of GetProcessTimes() in ReactOS, you can see that the information is copied from the process' KPROCESS. So, indeed, it's only physically present in a dump that includes kernel memory.
C:\tw>ls -l
total 0
C:\tw>cdb -c ".dump /ma .\tw.dmp;q" calc.exe | grep writ
Dump successfully written
C:\tw>cdb -c "lm;!peb;.dump /ma .\tw1.dmp;q" calc.exe | grep writ
Dump successfully written
C:\tw>cdb -c ".ttime;q" -z tw.dmp | grep -B 3 quit
Created: Wed Apr 5 20:03:55.919 2017 ()
Kernel: 0 days 0:00:00.046
User: 0 days 0:00:00.000
quit:
C:\tw>cdb -c ".ttime;q" -z tw1.dmp | grep -B 3 quit
Created: Wed Apr 5 20:04:28.682 2017 ()
Kernel: 0 days 0:00:00.031
User: 0 days 0:00:00.000
quit:
C:\tw>
Just bought a new server that runs WHM/cPanel, same as the old. Trying to use the built in tool to migrate multiple accounts / packages over. I'm able to connect to the other server, it lists out all the packages & accounts, I select all and start the process.
Then it goes through each package and account and fails to copy anything over. This is the error given for a sample account:
Command failed with exit status 255
...etc...
Copying Suspension Info (if needed)...Done
Copying SSL certificates, CSRs, and keys...Privilege de-escalation before loading datastore either failed or was omitted. at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1159
Cpanel::SSLStorage::_load_datastore('Cpanel::SSLStorage::Installed=HASH(0x3c72300)', 'lock', 1) called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1244
Cpanel::SSLStorage::_load_datastore_rw('Cpanel::SSLStorage::Installed=HASH(0x3c72300)') called at /usr/local/cpanel/Cpanel/SSLStorage/Installed.pm line 634
Cpanel::SSLStorage::Installed::_rebuild_records('Cpanel::SSLStorage::Installed=HASH(0x3c7230 0)') called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 308
Cpanel::SSLStorage::__ANON__() called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 1330
Cpanel::SSLStorage::_execute_coderef('Cpanel::SSLStorage::Installed=HASH(0x3c72300)', 'CODE(0x49ee958)') called at /usr/local/cpanel/Cpanel/SSLStorage.pm line 310
Cpanel::SSLStorage::rebuild_records('Cpanel::SSLStorage::Installed=HASH(0x3c72300)') called at /usr/local/cpanel/scripts/pkgacct line 2888
Script::Pkgacct::__ANON__('Cpanel::SSLStorage::Installed=HASH(0x3c72300)') called at /usr/local/cpanel/scripts/pkgacct line 2913
Script::Pkgacct::backup_ssl_for_user('jshea89', '/home/webwizard/cpmove-jshea89') called at /usr/local/cpanel/scripts/pkgacct line 532
Script::Pkgacct::script('Script::Pkgacct', '--use_backups', '--skiphomedir', 'jshea89', '/home/webwizard', '--split', '--compressed', '--mysql', 5.5, ...) called at /usr/local/cpanel/scripts/pkgacct line 111
==sshcontroloutput==
sh-4.1# exit $RET
exit
sh-4.1$ exit $RET
exit
sshcommandfailed=255`
A bit of a hack, but I went to /usr/local/cpanel/Cpanel/SSLStorage.pm line 1244 and commented out the Carp.
Accounts from my old dead server are now archiving :)
After some researching, I was able to determine that this was caused by incorrect ownership on the /home/user/ssl directory and its subdirectories. Someone had set the owner and group to root:root, when infact it should have been user:user.
Hopefully this helps some of you solve the problem!
I learnt that .tlist command in windbg dumps all the processes running in the system at the time of creating crash dump.
I would like to see the Memory Information of each process. So that it will help me to see if the system is over loaded by any specific process.
!process 0 1 will list all the processes and show memory related info for each. I issued this command using livekd and got all the processes. And here's my chrome process (which I picked out from the output):
PROCESS fffffa8007cb4200
SessionId: 1 Cid: 1158 Peb: 7efdf000 ParentCid: 0ff8
DirBase: 1b7962000 ObjectTable: fffff8a00addb010 HandleCount: 135.
Image: chrome.exe
VadRoot fffffa80090a6f80 Vads 169 Clone 0 Private 4037. Modified 3702. Locked 0.
DeviceMap 0000000000000000
Token fffff8a0091f9120
ElapsedTime 00:05:49.161
UserTime 00:00:00.000
KernelTime 00:00:00.000
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (8020, 50, 345) (32080KB, 200KB, 1380KB)
PeakWorkingSetSize 10137
VirtualSize 144 Mb
PeakVirtualSize 151 Mb
PageFaultCount 66631
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 5784
Job fffffa8009822e30
Note memory related properties such as "Working Set Sizes", "Virtual Size", etc.
ps. Works with livekd and with system memory dumps (which I believe is what livekd does).
Marc
This information is not contained in process dump. .tlist queries your current system, not the state when the dump was taken. If you can take a system dump, than you can check out processes and their memory usage, as Marc Sherman already answered.
Is there a problem with the Gnuwin32 port of "find"? It sort of works on my Windows XP command line, but I get blank stares when I try using file name pattern matching function. It's from "findutils-4.2.20" package. Had to rename to "gfind.exe" so Windows wouldn't confuse with CMD.EXE's "find".
Some samples from my Windows console:
C:\PROGRA~1\GnuWin32\doc\findutils\4.2.20\findutils-4.2.20>gfind .
.
./find.chm
./find.dvi.gz
./find.GID
./find.hlp
./find.html
./find.pdf
./find.ps.gz
That works.
Again, the following works:
C:\PROGRA~1\GnuWin32\doc\findutils\4.2.20\findutils-4.2.20>gfind . -ls
1970324837321105 0 drw-rw-rw- 2 cjohns89 0 0 Jun 11:34 .
1688849860610677 128 -rw-rw-rw- 1 cjohns89 0 130729 Mar 2005 ./fin
d.chm
1688849860610679 76 -rw-rw-rw- 1 cjohns89 0 74301 Mar 2005 ./fin
d.dvi.gz
21673573207016133 20 -rw-rw-rw- 1 cjohns89 0 16826 Jun 21:05 ./fi
nd.GID
1688849860610681 152 -rw-rw-rw- 1 cjohns89 0 154036 Mar 2005 ./fin
d.hlp
1688849860610683 224 -rw-rw-rw- 1 cjohns89 0 226750 Mar 2005 ./fin
d.html
1688849860610684 372 -rw-rw-rw- 1 cjohns89 0 379300 Mar 2005 ./fin
d.pdf
1688849860610685 200 -rw-rw-rw- 1 cjohns89 0 201163 Mar 2005 ./fin
d.ps.gz
But this doesn't do squat.
C:\PROGRA~1\GnuWin32\doc\findutils\4.2.20\findutils-4.2.20>gfind . -iname '*.pdf
' -ls
It just returns to the prompt. Am I (a novice) just mistaken in my use of syntax or is there a bug?
Chuck wrote:
gfind . -iname '*.pdf ' -ls
It's better without the apostrophe, since the Windows XP command line is an MS-DOS one.
For example:
gfind . -iname *.pdf -ls
A little wordy, but this link describes the issue. The short answer is that only double-quotes actually perform quoting in Windows' cmd.exe or command.exe.
Also, bear in mind that Windows expands *.pdf in the local directory first -- see Gnuwin32 find.exe expands wildcard before performing search.
I think the key to your issue is explained here
https://stackoverflow.com/a/3996353/8543838
Does not answer your question, but in the past I too had a few issues with GnuWin32 ‘find’ and I just wanted to let you know there is an alternative, part of ezwinports (another port of gnu tools).
I also seem to remember that ezwinports’s find was much faster than GnuWin32’s.
Also, my trick to avoid renaming Gnu tools that are the same as CMD’s built in functions (such as mkdir, echo and find) is to use ‘which find’ for example in a script. Then you know you are using gnu find and don’t need to touch anything.