In the past I knew, I was able to look at a crash dump and switch thru the
frames of a largish stack that includes both user and krnl function
executions. I was always under the illusion that for apps and krnl I need to
fire up two debugger instance, and always getting back to softice to tackle
this problem.
Now if I just embed a break point in my service ( right after the SCM
business is over), and start the machine with krenel debugger on, I break
into krnl debugger. But I can debug usr and krnl mode in one shot. I dont
need to change service start time, I dont need to muck around with registry
keys. Only perturbation to the test env., is that it is running under krnl
debugger. I bet this will also work for apps. Instead of directly invoking
under debugger, attaching this way gives me total control. I don’t need to
copy pdbs/src etc. Also this lets anyone to use commands specific to k-mode
( which is supposedly more than what is available in u-mode).
Since it k-mode debugger, even the scm related stuff could be stepped thru,
time is frozen.
-pro
On 2/8/07, Prokash Sinha wrote:
>
> First option is not so interesting as you pointed out ( being visible over
> the domain).
>
> Second one is just spectacular, I will try this. This is very nice.
>
> thanks once again 
>
> -pro
>
>
> On 2/8/07, Jason Shay wrote:
> >
> > Now that I know that’s your scenario, here’s some interesting
> > workarounds:
> >
> >
> >
> > 1) You can do ‘!!net use \dev\share /user:mydomain\myusername
> > ’ in the debugger to authenticate. But it goes clear-text, and
> > anyone connecting to the remote can see it in their history. So this may
> > not work for you.
> >
> >
> >
> > 2) Run the service under your own credentials during development.
> > That way, the IFEO debugger will also run under your credentials.
> >
> >
> >
> > 3) Attach after the service starts. Just use IFEO when you need to
> > debug startup.
> >
> >
> >
> > 4) There are tricks to debug both startup code and get the debugger
> > in your own credentials. You can only attach 1 “TRUE” debugger at a time.
> > But you can attach as many “-pv” (non-invasive) debuggers as you want.
> > Non-invasive mode can’t execute code, but it will freeze the process and
> > inspect memory. So you can perform a debugger swap like this:
> > - start service w/ debugger on via IFEO. You’ll want to run to your
> > entry point so SCM doesn’t kill the process.
> > - launch debugger as non-invasive against process using ?pv
> > - exit original debugger via ‘qd’ (which keeps the process alive,
> > suspended, with no real debugger attached)
> > - Launch another debugger (without ?pv). This will be the real deal, in
> > your security context
> > - ‘qd’ the non-invasive debugger.
> >
> >
> >
> > Jason
> >
> >
> >
> > From: xxxxx@lists.osr.com [mailto:
> > xxxxx@lists.osr.com] *On Behalf Of *Prokash Sinha
> > Sent: Thursday, February 08, 2007 7:04 AM
> > To: Kernel Debugging Interest List
> > Subject: Re: [windbg] Not finding private symbol path
> >
> >
> >
> > Thanks Jason,
> >
> >
> >
> > Yes, it is using that registry key to launch the service on the test
> > machine. And that is probably getting in my way to not like
> > \devmachine\blah. But that is okay, I can copy down the pdbs with the
> > binaries. Also thanks for telling the windbg’s preception about location of
> > syms.
> >
> >
> >
> > _TerminateThread();
> >
> >
> >
> > =pro
> >
> >
> >
> > On 2/7/07, Jason Shay wrote:
> >
> > Symbols are always loaded relative to the host debugger (in this case,
> > the one on the test machine). So c:\symcache will reference the c drive on
> > the test machine, even if you type it from the dev machine. You’ll want
> > \devmachine\blah.
> >
> >
> >
> > Security context is probably your issue. Are you using Image File
> > Execution Options to get the debugger to launch? If so, then the host
> > debugger is running in the security context of the service, which may not
> > have the network access to reach your dev box. Try a ‘!!net use’ to provide
> > your credentials, just to confirm, although most don’t like typing
> > credentials across the network that way. If you attach the debugger to a
> > running service rather than having it start with the service, you can get
> > the debugger in a different security context than the target app. Then a
> > symbol path as \devmachine\blah would work.
> >
> >
> >
> > Source code does not have the same limitation. That is, a debugger
> > client can set a source path and load source relative to itself. Usually
> > done via .lsrcpath, but your scenario is probably automatic. The PDB
> > (loaded on the server) knows the exact path where the source lives on your
> > dev machine (c:\mydev\sources.…). The client windbg is probably checking
> > that location to find source, so there is no network authentication
> > happening to load the source in your client debugger (running on the dev
> > box)
> >
> >
> >
> > Jason
> >
> >
> >
> >
> >
> > From: xxxxx@lists.osr.com [mailto:
> > xxxxx@lists.osr.com] *On Behalf Of *Prokash Sinha
> > Sent: Wednesday, February 07, 2007 9:34 PM
> > To: Kernel Debugging Interest List
> > Subject: Re: [windbg] Not finding private symbol path
> >
> >
> >
> > My idea is that symbols and source should be in the dev machine. And
> > syms should be resolved from the remote connected windbg client. Since
> > already a mapped drive is there (c:) I never tried to map the shared folder
> > to map again in the dev machine. But just to resolve this issues I tried to
> > map the sympath from test machine, and after I mapped, I tried on the
> > target(test) client to resolve thru mapped drive and same result.
> >
> >
> >
> > The scenario I look at is the following -
> >
> >
> >
> > For an app or service, make the windbg start automatically, and hand off
> > a remote ( using -s option at the start), optionally any of the pre-tailored
> > workspace etc. And get the remote on the dev machine. So I don’t need to
> > copy or make the src/sym available at the test machine.
> >
> >
> >
> > -pro
> >
> >
> >
> > On 2/7/07, Skywing wrote:
> >
> > I seem to recall there being some silly check to disallow UNC paths for
> > downstream stores in symbol paths in some circumstances. Do you get the
> >
> > same behavior with a drive letter mapping?
> >
> > –
> > Ken Johnson (Skywing)
> > Windows SDK MVP
> > http://www.nynaeve.net
> > < xxxxx@garlic.com > wrote in message news:xxxxx@windbg…
> > > This one thing I was able to solve …
> > >
> > > I’ve a test machine, and a dev machine. They both can see each other (
> > > ping-wise). They both can map shared drives of the other.
> > >
> > > Objective: Want to fire up an application debugger on the test machine
> > (
> > > in this particular case at the launch of a service, windbg would be
> > > invoked), once the debugger gets control ( try to give a remote ) use
> > > .server … Firewall settings are off on both machine. Connect to
> > the
> > > remote from the dev machine.
> > >
> > > But I can never make the sympath to accept c:\mysymPath. Always
> > says
> > > ‘Inaccessible Path’ Tried unc name to patch the \devMachineName etc.
> > >
> > > The symbol mapping are tried from dev machine.
> > >
> > > But if I copy the symbols locally to the test machine, it is fine. And
> > > source from the dev machine is accessible. Syms are resolved.
> > >
> > > What am I missing?
> > >
> > > thanks
> > > -pro
> > >
> >
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > — You are currently subscribed to windbg as: xxxxx@winse.microsoft.comTo unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to windbg as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > — You are currently subscribed to windbg as: xxxxx@winse.microsoft.comTo unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> > —
> > You are currently subscribed to windbg as: unknown lmsubst tag argument:
> > ‘’
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>