How to set windbg as postmortem debugger for elevated applications? - windbg

I have windbg registered as postmortem debugge (via -I command-line switch) and all works fine for non-elevated applications. But if elevated applications crashes, windbg starts and displays "Could not attach to process. Access is denied" error. Is it possible to somehow configure windbg so it will work as postmortem debugger for elevated apps?

Since you mentioned that it's an x86 app on an x64 system, you need to set these regkeys in Wow6432Node:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]
"UserDebuggerHotKey"=dword:00000000
"Debugger"="\"C:\\debuggers\\windbg.exe\" -p %ld -e %ld -g"
"Auto"="1"
Note that these are both string values (REG_SZ) and I'm assuming that the windbg.exe is installed in C:\debuggers. Change that as appropriate.

Related

Perl Scripts on Windows 10 run from Explorer but not Command Prompt

I've installed ActiveState Perl on my new Windows 10 PC. I've installed the same exact version of Perl on several of my own PC's, and it's installed on 100's of other users' PC's in my company. Same exact install, created by me.
This is the first time trying this on Windows 10. The basic actions of double-clicking a Perl script (*.pl) in Explorer cause a console window to open and Perl to run the script.
Also, in Windows Command Prompt, I can type perl.exe script.pl, and the script runs fine. But, when I just type script.pl, nothing happens. No output, no errors, no perl.exe processes visible in Task Manager.
The first time I ran a Perl script (from Windows Command Prompt, I believe, using just the script.pl syntax), Windows popped up a window asking me what program I wanted to use to open this file. Perl was the default, and I clicked OK.
I've never seen that window in Windows 7 or 8, so I'm thinking it's something specific to Windows 10, and that it's the thing that's somehow preventing me from just typing script.pl. Because, when launching script.pl, I'm requiring the file associations to pick the right program, but when I type perl.exe script.pl, perl.exe is being launched directly. But, that Windows 10 "pick your default program" thing is getting in the way when running from the command prompt by messing up the file associations.
Not 100% sure why it works from Explorer, though, but I'm pretty sure that I need to clear that default program thing. I removed the registry entry for .pl files under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, but that didn't help.
This seems to be a more generic problem with Windows 10, or possibly just my installation of it, or a Group Policy I'm not aware of.
The following commands (run in a Admin command prompt) work fine in Windows 8.1 but not Windows 10:
assoc .foo=Foobar
ftype Foobar=C:\WINDOWS\system32\foo.bat %1
echo #echo off > foo.bat
echo echo The filename is %1 >> foo.bat
echo hi > foo.foo
foo.foo
The result should be the output:
The filename is C:\WINDOWS\system32\foo.foo
But Windows 10 does nothing. It seems to only allow built-in apps to be associated in this manner, and not BAT scripts of downloaded/installed EXEs.
Turns out that Microsoft reversed the polarity of a Registry setting in Windows 10, and this is biting other Perl programmers too. The solutions is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\InheritConsoleHandles to "0".
MSDN post here: https://social.msdn.microsoft.com/Forums/en-US/f19d740d-21c8-4dc2-a9ab-d5c0527e932b/nasty-file-association-regression-bug-in-windows-10-console
Make sure your PATHEXT environment variable has .pl in it.

Firebird tools gfix gbak do not launch

Running Firebird 2.5 as a service on a local 64-bit Windows 10 machine.
isql, qli and a bunch of the other tools run just fine.
However when I try an launch gfix, gbak and gstat the window barely opens before disappearing. It does this so quickly nothing is visible.
Any recommendations for dealing with this?
My actual goal at the moment is to change a firebird database from read-only to read-write. Which you can do using gfix http://www.firebirdsql.org/manual/gfix-dbmode.html
If there is some other method to change to read-write I'd happily use it.
The tools gfix, gbak and gstat are command line utilities. They expect certain command line options, and they print their output to the console. If you start them by double-clicking them in explorer, or executing them from the Run prompt, a console is opened, output is written (the usage information as you haven't specified the necessary command line options), and then it exits, closing the console immediately.
This means that if you want to run them and see the output, you need to execute them from the command prompt (cmd), or from a batch-file that has pause at the end.
The fact qli and isql work by opening them from explorer (or run) is because they are interactive tools, waiting for your input.

Command line installer issues

Am attempting to run installer using command line using -c option.
Command line execution appears like this:
E:\dev>MyApp_32.exe -c
E:\dev>This will install App on your computer.
OK [o, Enter], Cancel [c]
E:\dev> (showing the Windows command line is confusing to user)
Welcome .. (text of 2nd screen)
Typing "c" or "Cancel" doesn't work. It always takes enter key as input and proceeds to next screen.
Pressing enter transfers control back to windows's command shell, then back to installer. This looks confusing to user. It doesn't give a unified experience to user.
Is it possible to provide input via a silent file ? i.e. a text file with pre-selected inputs?
Am using 32 bit installer on Win 7 Professional x64 with Java 1.6 installed.
The problem is that the installer is a GUI application, it cannot take control of a WIndows terminal in this way. If you start it via
start /wait MyApp_32.exe -c
the command line prompts will not be displayed.
You can run set a response file with the -varfile argument, see the help for more information.

Running perl script with Net::SSH::Expect package in cygwin environment from DOS CMD

I am sucessed to run the Perl script which uses Net::SSH::Expect package from the cygwin command prompt. but i want to schedule the same script through the task schedular of windows 2003 or throught the crontab of cygwin or to run from DOS command prompt the script is failing in middle with below error.
Error:
SSHAuthenticationError Login timed out. The input stream currently has the conte
nts bellow: Pseudo-terminal will not be allocated because stdin is not a termina
l.
at /usr/lib/perl5/site_perl/5.10/Expect.pm line 828
Password:
can any body help me out in this..
Thanks in advance.
kishore.
You need to either force or disable the allocation of the pseudy TTY in your command line which launches SSH, by passing the -T or -t option to SSH. From the SSH man page:
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbi-
trary screen-based programs on a remote machine, which can be
very useful, e.g. when implementing menu services. Multiple -t
options force tty allocation, even if ssh has no local tty.

Is it possible to debug win2003 IIS crash dump using windbg on windows XP?

I downloaded symbols for windows2003 server from here http://msdn.microsoft.com/en-us/windows/hardware/gg463028
I did what is described here - http://blogs.msdn.com/b/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx. But when I try to run !threadpool it says
0:024> !threadpool
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks___.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
This occurs because you have a different minor version of .net on your computer than the server has. I don't mean .net 3.5 vs 4.0, I mean version a.b.c.d.dll vs e.f.g.h.dll.
You need to get a copy of c:\windows\microsoft.net\framework\v2.0.50727\mscordacwks.dll from the windows2003 server.
Then, follow the steps in this post: http://blogs.msdn.com/b/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx.
Try this first:
!sym noisy
.symfix c:\mylocalsymcache
.cordll -ve -u -l
If that doesn't work, then you'll rename the mscordacwks.dll file, copy it to the symbol location specified on your machine, and try again.
Please do not overwrite the file on your computer with the one from the windows 2003 server. :)