That is a VERY fine point of semantics; what is the issue is
(a) the existing version of the OS shut down
(b) a boot cycle was initiated
There is no reason to expect that this is going to load the same version of
the OS that existed at (a) during time (b).
joe
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jim Donelson
Sent: Tuesday, November 25, 2008 3:08 PM
To: Kernel Debugging Interest List
Subject: {Disarmed} Re: [windbg] WinDbg 6.10.3.233 doesn’t close PDB files
Ya, but then you are not re-booting.
You are new booting…
On Tue, Nov 25, 2008 at 1:21 PM, Joseph M. Newcomer
wrote:
See below…
_____
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jim Donelson
Sent: Tuesday, November 25, 2008 12:00 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] WinDbg http: MailScanner warning:
numerical links are often malicious: 6.10.3.233 doesn’t close PDB files
>This is patently wrong. The next time the debugger reconnects, the OS
may
>be different. It might even be a different system altogether.
Interesting, you change the os between reboots. How is that done?
By the most trivial of techniques. Selecting a different operating system
in the boot-time menu.
*
>So does rebooting the system to stop a runaway app. Doesn’t mean it’s the
>most efficient approach to dealing with that particular problem …
I thought the issue was re-building the driver, normally you reboot so you
can re-build and re-load, or because you raised an exception in the kernel
and found the issue, so now you need to re-boot and re-build.
****
Very often the problem in a driver does not require a reboot; just
unplugging the device and then plugging the device back in again. PnP will
unload the driver when it is unplugged and reload the driver when it detects
the device, and in between you do the rebuild. If you have enabled the
dynamic download (“map file”) capability in WinDbg, it will download the new
driver from the connected development machine with no effort on your part.
In fact, one of the great motivators for building robust drivers is that
even when they are wrong, all IRPs get completed anyway, so the driver is
always in a stable and recoverable state. Once my students get beyond the
“oh, it blue-screened” stage of development, they can usually use this
technique and only need to reboot the test machine infrequently.
joe
*****
On Tue, Nov 25, 2008 at 11:53 AM, Philip D. Barila
wrote:
“Jim Donelson” wrote in message news:xxxxx@windbg…
> Good point - this has been discussed.
> Not releasing the files on reboot is a good thing. Then it does not have
> to
> reload them.
This is patently wrong. The next time the debugger reconnects, the OS may
be different. It might even be a different system altogether.
> When I need to rebuild, I just close windbg. That always works.
So does rebooting the system to stop a runaway app. Doesn’t mean it’s the
most efficient approach to dealing with that particular problem …
Phil
–
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
—
You are currently subscribed to windbg as: xxxxx@jimdonelson.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
— You are currently subscribed to windbg as: xxxxx@flounder.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.
—
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: unknown lmsubst tag argument:
‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
–
This message has been scanned for viruses and
dangerous content by http:</http:> MailScanner, and is
believed to be clean.</http:>
