When trying to debug the installation process of a msi installer using CDB as,
cdb -g -G -logo c:\log.log c:\temp\abc.msi
I get the following error saying
"Cannot execute abc.msi", Win32 error On193
"%1 is not a valid Win32 application."
Debuggee initialization failed, Win32 error On193
"%1 is not a valid Win32 application"
There are no spaces in the path to the installer either.
You can use Image File Execution Options (IFEO) to have the OS launch a debugger and then have the debugger launch the debuggee. Under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options create a key called msiexec.exe. In that new key create a REG_SZ value named Debugger and set that to <path_to_cdb> -g -G -logo c:\log.log c:\temp\abc.msi
Note: I normally use this with windbg.exe instead of cdb.exe. I think cdb.exe may need a command prompt already so try with windbg.exe or ntsd.exe.
Note2: You may want to remove the -g option so that you have a chance to set some breakpoints before execution begins.
You can find more info on IFEO in the debugger.chm help file that comes with Debugging Tools for Windows.
Related
I'm trying to analyze the performance of a Rust executable on Windows, but cannot seem to instrument the executable image using the VSInstr.exe tool.
To get started I set up a binary cargo package (cargo new --bin sample), and enabled generation of a PDB by adding
[profile.release]
debug = true
to the standard Cargo.toml file. Executing cargo build --release produces both sample.exe and sample.pdb. Navigating to target/release and executing vsinstr sample.exe produces the following diagnostic (VS2017 and VS2019, respectively):
Error VSP1011: Unable to obtain debug information. Link with the /Profile linker switch.
Unable to obtain debug information. Link with the /PROFILE linker switch.
Fair enough, so let's add the following .cargo/config file:
[build]
rustflags = ["-C", "link-args=/PROFILE"]
to pass the required flag to the linker. Running cargo build --release again produces the same artifacts, sample.exe and sample.pdb. Attempting to instrument the image using vsinstr sample.exe now produces the following diagnostic (VS2017 and VS2019, respectively):
Error VSP1033: The file '<path>\sample.exe' does not contain a recognized executable image.
The file does not contain a recognized executable image.
I'm not sure how to proceed from here, or how to further diagnose the core issue.
Is there something wrong with what I'm doing?
Am I running into a limitation of rustc/Clang?
Most importantly, how do I fix the issue?
Notes:
The /PROFILE linker option is documented to be "available only in Enterprise (team development) versions". That information seems outdated. Using the option on a C++ application in Visual Studio 2019 Community had the desired effect.
I've verified, that the /PROFILE flag gets passed to the linker by adding the -Z print-link-args flag to the rustflags in .cargo/config to see the actual linker command line.
Profiling any given Rust application in sample mode (CPU Usage) from the Visual Studio IDE works as long as the respective PDB is available. That's helpful, but I'd really like to get accurate call graphs, so instrumentation is required.
Alongside VSInstr.exe, Visual Studio also ships a binary called vsinstr.legacy.exe, that apparently dumps out more information. Running this against the Rust executable produces a list of warnings that have the following shape:
Warning VSP2005: Internal instrumentation warning: Block start at 1400016D9 is inside instruction at 1400016D8. Removed.
The addresses in all messages differ exactly by 1, which looks an awful lot like an off-by-one error, presumably in the code that produces the PDBs.
Whenever I open a new Command Prompt window it prints
Microsoft Windows [Version 10.0.18362.476]
(c) 2019 Microsoft Corporation. All rights reserved.
C:\Users\USERNAME>■#
'■#' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\USERNAME>
and I can't figure out where it comes from. It interferes with a C# application I'm using that tries to run some-package --version through a Process instance, and based on processInstance.ExitCode build the UI, but that gets interrupted due to this.
My best guess is that cmd.exe tries to execute something when launched but I couldn't find a .bashrc equivalent. I tried to remove the Path variables in both User variables and System variables if any
Path values might have pointed to a non-existing directory/file, but it still comes up.
Any ideas how I could debug this?
When running cmd /D it did not come up, which made me look at the AutoRun entries in the registry which are located in:
HKLM\Software\Microsoft\Command Processor
and
HKCU\Software\Microsoft\Command Processor
Here I found an AutoRun entry that I deleted which solved the problem.
I have ust started using debugger but it shows this error on pressing move to cursor on codebocks.
Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\anand\software\installed\CodeBlocks\dp\
Adding source dir: C:\anand\software\installed\CodeBlocks\dp\
Adding file: C:\anand\software\installed\CodeBlocks\dp\bin\Debug\dp.exe
Changing directory to: C:/anand/software/installed/CodeBlocks/dp/.
Set variable: PATH=.;C:\MinGW\bin;C:\MinGW;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\Git\cmd;C:\HashiCorp\Vagrant\bin;C:\Users\Yash\AppData\Local\Microsoft\WindowsApps
Starting debugger: C:\MinGW\bin\gdb.exe -nx -fullname -quiet -args C:/anand/software/installed/CodeBlocks/dp/bin/Debug/dp.exe
failed
I had a similar problem with not being able to start the debugger and it turned out I forgot to install it in the first place. Check whether you have gdb present in your system -- if you're running on Windows and using MinGW then look into C:/MinGW/bin for gdb.exe
I have Qt Creator 4.4.1 installed on Windows 10 64 bit. I have also bash on ubuntu on windows installed. I want to call bash from Qt creator in order to execute some linux commands on the project directory by creating a custom building process step but unfortunately I get the following error:
16:21:50: Running steps for project myTest...
16:21:50: Could not start process "bash" foamExec
Error while building/deploying project myTest (kit: Desktop Qt 5.9.3 MinGW 32bit)
When executing step "Custom Process Step"
16:21:50: Elapsed time: 00:00.
I have also tried the following steps:
To specify the full path of bash: C:\Windows\System32\bash.exe but it fails with the
same error.
To call cmd to execute a .bat script that contains the
following code: bash -c "my command that I want to execute" but I get the following error as well:
``16:30:31: Running steps for project myTest...
16:30:31: Starting: "C:\WINDOWS\system32\cmd.exe" /c "bash -c 'foamExec wmake'"
'bash' is not recognized as an internal or external command,
operable program or batch file.
16:30:31: The process "C:\WINDOWS\system32\cmd.exe" exited with code 1.
Error while building/deploying project myTest (kit: Desktop Qt 5.9.3 MinGW 32bit)
When executing step "Custom Process Step"``.
I tried to create external commands in Qt from: Tools > External, but I get always the same error.
I tried also to run Qt creator from bash terminal: "/mnt/c/Qt/Qt5.9.3/Tools/QtCreator/bin/qtcreator.exe" Qt Creator starts fine but again it doesn't recognize bash command..
Can you please explain me why Qt Creator cannot recognize bash?
This is not a complete answer, but maybe someone will figure out the rest.
The "bash not recognized" part is because of this issue - basically, Qt is a 32-bit application, while bash.exe is a 64-bit application, and since Qt's cmd is 32-bit, it cannot find it.
However, addressing this introduces a different error. I've tried the following:
Running bash directly, using "C:\Windows\sysnative\bash.exe" path
Wrapping bash in 64-bit cmd.exe (run "C:\Windows\sysnative\cmd.exe /C bash")
Wrapping bash in 32-bit cmd.exe (run "cmd /C C:\Windows\sysnative\bash.exe")
Neither of the above work, instead failing with "The process exited with code -1". This happens even with a 64-bit version of QtCreator - it seems that there's something about WSL that prevents it from running inside QtCreator.
I am currently trying to debug a memory leak in one of my applications (yeah, that crap again...), and trying to set gflags settings, but the dialog won't open up. I installed the Windows 10 SDK (I am on Windows 7 x64), but it said it works on Win7 as well in the description, so why can I not use it at all?
If I start gflags from command line, nothing at all happens, no error, no feedback, nothing.
Anybody an idea as to what might be happening on my system?
According to http://www.osronline.com/showThread.CFM?link=278979, you'll need to wait for a new version (that apparently doesn't exist as of Jan 2017) that contains gflagsui.dll
Known issue that will be fixed in an upcoming release. You should be able to use
the version of GFlags that is installed with any of the 8 or 8.1 kits, or copy
the gflagsui.dll from those.
You can also use GFlags via the command-line:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff549566(v=vs.85).aspx
Try opening an elevated command prompt.
cd to install folder
(C:\Program Files (x86)\Windows Kits\10\Debuggers\x64)
Type gflags /?
It will probably tell you you only get the dialog box if gflagsui.dll is available, but there is no info how to get it.
(if you don't use an elevated command prompt you'll get UAC, then you'll see a console window open and quickly exit)
So for now you'll need to use the command line...