Ok i used the below command to make my 32 BIT Excel use address > 2GB
editbin /largeaddressaware EXCEL.EXE
Now i want to undo this.. Please help me.. i tried in google but could not find an undo command
editbin /largeaddressaware:no excel.exe
Related
I am trying to follow this WinDBG tutorial, and at some point, it requires the Microsoft public symbol server to be set up. I ran the command:
set _NT_SYMBOL_PATH=srv*DownstreamStore*https://msdl.microsoft.com/download/symbols
followed by
.symfix+ C:\MySymbols
but I get the infamous error message
'.symfix+' is not recognized as an internal or external command, operable program or batch file.
My environment, running the command systeminfo | findstr /B /C:"OS Name" /C:"OS Version" is:
OS Name: Microsoft Windows 10 Home
OS Version: 10.0.19041 N/A Build 19041
I would appreciate it if you could help me know what is the problem and how I can solve it.
The command
set _NT_SYMBOL_PATH=...
sets an environment variable that attempts to tell all debugging programs where to download symbols. This affects WinDbg, Visual Studio, Process Explorer and others.
The command
.symfix
is WinDbg specific and is an equivalent to the above. Setting both is not necessary.
Please note that you should not enter this part
srv*DownstreamStore*https://msdl.microsoft.com/download/symbols
literally. You should replace the part DownstreamStore by a place where you want the downloaded symbols to be stored on your hard disk. So in your case, this should be C:\MySymbols.
The command .symfix just takes DownstreamStore as an argument and puts srv* before and *https://msdl.microsoft.com/download/symbols after that argument. So using
.symfix C:\MySymbols
is equivalent to
.sympath srv*C:\MySymbols*https://msdl.microsoft.com/download/symbols
but much easier to type.
The + in these commands (.sympath+ or .symfix+) will append another symbol path, assuming that you already had one set up before.
Neither set _NT_SYMBOL_PATH nor .symfix nor .sympath will actually download symbols. The symbols will be downloaded on demand. Use ld*; reload /f when being attached to a process for downloading symbols.
Or, as mentioned by yourself, use the command line tool symchk.
As mentioned in the comment above, the .symfix command is a WinDbg one, which needs to be entered at the software's command line, not the Windows terminal cmd!
However, there are certain command-line tools that can do the job, partly! The complete "WinDbg Command-Line Options" documentation can be seen here. Also, there is the symchk tool coming with the "Windows Driver Kit (WDK)". One can download the "Microsoft's public symbol" database using the command:
symchk "path\to\binary" /s srv*DownstreamStore*https://msdl.microsoft.com/download/symbols
P.S. Usefull common WinDbg commands
Hopefully, this question can be resolved, as I've been searching all over the web for answers to no avail. Does Cygwin have a command to display cpu % of a Windows process? I know that the command top can display this information, but it only displays Cygwin processes and not Windows. There's another command, ps, but this doesn't display cpu %. Perhaps there's a command that has the best of both top and ps.
Well, you don't need "native" Cygwin application to do that, because Cygwin can execute also native Windows' executables. In fact, Cygwin's "native" executables are Windows' native executables. They just use Cygwin's DLLs to map Linux system calls to Windows' ones.
Just use for example package PsTools from SysInternals (now part of Microsoft). It contains pslist which is able to output running Windows' processes information.
This works for me in cygwin, to check if any audio is playing:
t1=`/cygdrive/c/windows/system32/tasklist /fi "ImageName eq audiodg.exe" /v /nh`
(remove the "/nh" to see column headers)
(Actually, this only returned the total cpu usage. But i put it in a loop in a script w/ 'date +%s to get the time, and then calculated the percentage.)
Redirecting CMD Commands To An EXE File
Long story short, basically I have the problem that every time I run BCDedit on the .BAT that I converted into an .EXE it never worked and I thought that the reason why it wasn't work was because it wasn't on Path but my Path was fine and even if it was on Path is set by default thanks to foxidrive.
Now my main problem is that is there a way I can convert it to an .EXE file with every single command working, is there a technique I could use to get BCDedit working as an .EXE file?
All of the commands do work it just BCDedit and I say if every single command would work so if somebody has a similar command problem like me they know how to figure it out, it works perfectly as batch but is there a way I can convert it and make BCDedit still work as an .EXE?
Please answer As Soon As Possible and if you want to take a look at my Path and Batch the visit the link at the top.
Thank you so much!
Compile this batch file and see if it works:
#echo off
bcdedit /?
pause
Then try this version:
#echo off
c:\Windows\System32\bcdedit.exe /?
pause
Just as the SysWow64 Redirection link you listed states. If you want a x86 application to call the 64-bit system directory you need to call the bcdedit application as follows.
%SystemRoot%\SysNative\bcdedit
This is because of Windows backwards compatibility measures, it is looking at C:\Windows\SysWOW64 instead of C:\Windows\System32. Another alternative would be to compile the script as both x86 and 64-bit, but then you could only use each on the respective systems.
Update for Comments
Even though the path is correct, an x86 application will execute commands or batch scripts against the C:\Windows\SysWOW64\cmd.exe which will cause the path redirection issue. Example to illustrate my point. On a 64-bit version of Windows, open C:\Windows\SysWOW64\cmd.exe and using Windows explorer create two unique files , one is C:\Windows\System32\unique_test64.txt and the other in C:\Windows\SysWOW64\unique_test86.txt. Now on the x86 command prompt enter if exist C:\Windows\System32\unique_test86.txt echo true. You will see that it is being redirected to SysWOW64 and will print true. And if you enter if exist C:\Windows\System32\unique_test64.txt echo true, nothing will be found.
Screenshot Example: http://i.imgur.com/K4kkI29.png
I am in a small bind. The program in question can be installed in the program files directory (64bit) or X86 path. The program is already installed in over 200 machines. I am fairly certain the default install path was X86 as that's the default. I am not certain and must cover both scenarios. The original sys admin that installed this didn't use an .msi so I'm left with what I've found as ""C:\Program Files\InstallShield Installation Information{78AC336D-25F6-4916-A711-2EA2F69E0319}\setup.exe" as the command provided by one utility to remotely uninstall said application I found. Didn't work and I cannot attempt to push this out in hopes it'll work.
Given this problem, is there a way to uninstall this program via a script that would check both program files and X86 paths and uninstall depending on location? OR, is there a script that will just flat out uninstall the program regardless without the concern for the X86/program original install location. I just need to uninstall it period across all of these machines. The install .bat is good to go. What I cannot do is just get window to uninstall X application via a script for 32 or 64 bit machines.
I've tried MsiExec.exe /X{78AC336D-25F6-4916-A711-2EA2F69E0319} /quiet with no go. I can try to install the .msi this time around but am lost and my knowledge is limited with scripting or any uninstall scripts for telling "end users" without confusing them to just click here. I could tell them to go to control panel, etc..but they'll be lost....typical.
Any ideas on how to script this uninstall given it wasn't an original .msi and I am not sure how to get something working? I'm open to anything. I have two days to get this fixed and I'm in panic mode...
Any ideas or help on code would be greatly appreciated.
Regards,
Brian
wmic can call an uninstaller. I haven't tried this, but I think it might work.
wmic /node:computername /user:adminuser /password:password product where name="name of application" call uninstall
If you don't know exactly what the program calls itself, do
wmic product get name | sort
and look for it. You can also uninstall using SQL-ish wildcards.
wmic /node:computername /user:adminuser /password:password product where "name like '%j2se%'" call uninstall
... for example would perform a case-insensitive search for *j2se* and uninstall "J2SE Runtime Environment 5.0 Update 12". (Note that in the example above, %j2se% is not an environment variable, but simply the word "j2se" with a SQL-ish wildcard on each end. If your search string could conflict with an environment or script variable, use double percents to specify literal percent signs, like %%j2se%%.)
If wmic prompts for y/n confirmation before completing the uninstall, try this:
echo y | wmic /node:computername /user:adminuser /password:password product where name="whatever" call uninstall
... to pass a y to it before it even asks.
I haven't tested this, but it's worth a shot anyway. If it works on one computer, then you can just loop through a text file containing all the computer names within your organization using a for loop, or put it in a domain policy logon script.
Further reading on wmic
More reading on wmic
Assuming you're dealing with Windows 7 x64 and something that was previously installed with some sort of an installer, you can open regedit and search the keys under
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
(which references 32-bit programs) for part of the name of the program, or
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
(if it actually was a 64-bit program).
If you find something that matches your program in one of those, the contents of UninstallString in that key usually give you the exact command you are looking for (that you can run in a script).
If you don't find anything relevant in those registry locations, then it may have been "installed" by unzipping a file. Because you mentioned removing it by the Control Panel, I gather this likely isn't then case; if it's in the list of programs there, it should be in one of the registry keys I mentioned.
Then in a .bat script you can do
if exist "c:\program files\whatever\program.exe" (place UninstallString contents here)
if exist "c:\program files (x86)\whatever\program.exe" (place UninstallString contents here)
In my experience, to use wmic in a script, you need to get the nested quoting right:
wmic product where "name = 'Windows Azure Authoring Tools - v2.3'" call uninstall /nointeractive
quoting both the query and the name. But wmic will only uninstall things installed via windows installer.
I am using windows source insight. In this only the basic text editor is available. Is there any vim plugin available to use it in windwos source insight?
According to the docs (search for ShellExecute), you should be able to invoke a ShellExecute with an arbitrary program. If VIM is associated with a certain file as editor, this should work:
ShellExecute edit <yourfile>
If VIM is for some strange reason not the default editor for a certain file, you should try
ShellExecute "" C:/Path/to/vim.exe <yourfile>
Thay way, you should be able to call any external tool from Source Insight.
add customer command in source insight and bind a new short key.
"C:\Program Files (x86)\Vim\vim81\gvim.exe" --remote-silent +%l %f