Hello all,
I have successfully installed and debugged the installation and
uninstallation procedure.It works fine.But when I try to debug the
functionality like IRP_MJ_CREATE and IRP_MJ_CLOSE, it is very very slow.It
tyales at least 15 seconds to complete one step over or step into and til
that time the procedure usage is 100%. It is not the case that I am having
a slow machine. I have P IV 256 MB Ram 1.6 GHz. still it is very slow.It
is comparatively fast while I debugged the installation and
uninstallation.
What might be the cause? I am using WinDbg 6.0.
One more thing is that if I place a breakpoint after 5-6 statements the
the current instruction then it takes same time to complete one step over
or step into.Strange.
Anand.
This might be a stupid answer… but i hope you have set your COM - baud
rate to a higher value.
-----Original Message-----
From: Anand [mailto:xxxxx@lambenttek.com]
Sent: Thursday, August 08, 2002 6:10 PM
To: NT Developers Interest List
Subject: [ntdev] Very slow processing…
Hello all,
I have successfully installed and debugged the installation and
uninstallation procedure.It works fine.But when I try to debug the
functionality like IRP_MJ_CREATE and IRP_MJ_CLOSE, it is very very
slow.It tyales at least 15 seconds to complete one step over or step
into and til that time the procedure usage is 100%. It is not the case
that I am having a slow machine. I have P IV 256 MB Ram 1.6 GHz. still
it is very slow.It is comparatively fast while I debugged the
installation and uninstallation.
What might be the cause? I am using WinDbg 6.0.
One more thing is that if I place a breakpoint after 5-6 statements the
the current instruction then it takes same time to complete one step
over or step into.Strange.
Anand.
You are currently subscribed to ntdev as: xxxxx@wipro.com To
unsubscribe send a blank email to %%email.unsub%%
Hmm,
interesting topic. I have exact the same problems using WinDBG
V6.0.0007.0. When single stepping, after each step the memory usage
of WinDBG increases about 100 MB (yes, megabytes!) and consumes 100%
CPU for some seconds. What is fatal is the fact, that after a single
step is done, memory usage decreases not as it increased before…
So after a few steps the system is swapping continuosly and WinDBG
dies because the system is “out of memory”.
I am using Windows XP Pro and this problem occures also when doing
(local) user mode debugging.
Has anybody any hints on this?
Thanks,
Holger
This might be a stupid answer… but i hope you have set your COM - baud
rate to a higher value.=20-----Original Message-----
From: Anand [mailto:xxxxx@lambenttek.com]=20
Sent: Thursday, August 08, 2002 6:10 PM
To: NT Developers Interest List
Subject: [ntdev] Very slow processing…Hello all,
I have successfully installed and debugged the installation and
uninstallation procedure.It works fine.But when I try to debug the
functionality like IRP_MJ_CREATE and IRP_MJ_CLOSE, it is very very
slow.It tyales at least 15 seconds to complete one step over or step
into and til that time the procedure usage is 100%. It is not the case
that I am having a slow machine. I have P IV 256 MB Ram 1.6 GHz. still
it is very slow.It is comparatively fast while I debugged the
installation and uninstallation.
What might be the cause? I am using WinDbg 6.0.
One more thing is that if I place a breakpoint after 5-6 statements the
the current instruction then it takes same time to complete one step
over or step into.Strange.
Anand.
You are currently subscribed to ntdev as: xxxxx@wipro.com To
unsubscribe send a blank email to %%email.unsub%%
wrote in message news:xxxxx@ntdev…
>
> Hmm,
>
> interesting topic. I have exact the same problems using WinDBG
> V6.0.0007.0. When single stepping, after each step the memory usage
>
My first hint would be to upgrade the version of WinDbg that you’re using.
After that, understand that single step CAN be a slow process – but it
shouldn’t be VERY slow. If you can repro this problem on the latest WinDbg,
then try the WINDBG forum (sign up at http://www.osr.com/lists)
Peter
OSR
I had this problem in both v6.0.7.0 and v6.0.17.0. What I did was recreate
workspace and lower baudrate to 57600. Lowering it after debugger was
connected did not solve the problem. However, setting up my workspace from
scratch and specifying baudrate as 57600 helped pretty well.
-htfv
----- Original Message -----
From: “Peter Viscarola”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Friday, August 09, 2002 4:56 PM
Subject: [ntdev] Re: Very slow processing…
> wrote in message news:xxxxx@ntdev…
> >
> > Hmm,
> >
> > interesting topic. I have exact the same problems using WinDBG
> > V6.0.0007.0. When single stepping, after each step the memory usage
> >
>
> My first hint would be to upgrade the version of WinDbg that you’re using.
>
> After that, understand that single step CAN be a slow process – but it
> shouldn’t be VERY slow. If you can repro this problem on the latest
WinDbg,
> then try the WINDBG forum (sign up at http://www.osr.com/lists)
>
> Peter
> OSR
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@vba.com.by
> To unsubscribe send a blank email to %%email.unsub%%
>
Peter, in what case single stepping is slow ? Inquiring minds want to know.
Alberto.
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Friday, August 09, 2002 9:56 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Very slow processing…
wrote in message news:xxxxx@ntdev…
>
> Hmm,
>
> interesting topic. I have exact the same problems using WinDBG
> V6.0.0007.0. When single stepping, after each step the memory usage
>
My first hint would be to upgrade the version of WinDbg that you’re using.
After that, understand that single step CAN be a slow process – but it
shouldn’t be VERY slow. If you can repro this problem on the latest WinDbg,
then try the WINDBG forum (sign up at http://www.osr.com/lists)
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> Peter, in what case single stepping is slow ? Inquiring minds want to
know.
>
>
I’m specifically addressing the bag here… single-steps can often be quite
slow as a result of symbol-table lookups and such. Depends what you’re
stepping IN to, OVER, or TO.
P
Actually I believe that the problem is the communications link. Correct me
if I’m wrong, but looks to me like Windbg is host-centric, hence the
problem. SoftICE is target-centric, the host layer is just a terminal
program, all of the processing takes place on the target and doesn’t need to
communicate to the host until the information is ready to be displayed. And
by the way, that’s one of the advantages of single-machine debugging,
there’s no communications delay anywhere.
Alberto.
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Friday, August 09, 2002 4:14 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Very slow processing…
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> Peter, in what case single stepping is slow ? Inquiring minds want to
know.
>
>
I’m specifically addressing the bag here… single-steps can often be quite
slow as a result of symbol-table lookups and such. Depends what you’re
stepping IN to, OVER, or TO.
P
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
Ya Alberto, you are very right, unfortunately NTICE has a lot of other
issues, like inability to corectly parse hughe symbols tables from .PDB
generated with latest MS compilers, especially it cannot handle locals
correctly, it spits out wrong stack backtraces sometimes,
it ruins stack backtraces in crash dumps sometimes, because you may end
having NTICE hook functions into the stack, which cannot be correctly
backtraced because NTICE.SYS does not come with symbols and FPO data to help
for this, it lacks many usefull commands for FS driver developing, its a
pain in the ass to debug deadlocks or livelocks with NTICE.
Your hacked interface for using Windbg extensions works all the time, save
for the moments it doesnt work at all,
for many many commands all you get is a fault while processing the command,
you dont have a native mechanism for extending NTICE command set, using a
scripting language or a clear plugin interface with full access to base
NTICE functions.
Finally, your company seems much more interested to make minor cosmetic
improvements on NTICE, instead of focusing on real stuff who would help
developers. Its much more important to have an accurate debugger than having
“user defined” popup menus, workspaces in loader, and other minor things
like this. Frankly , since NuMega was acquired by Compuware, all I can see
is a constant quality drop and lack of pace into developing NTICE. I really
think you should focus on important things, donno who decide what the hell
will go into the next version of NTICE, but
judging after the last X versions “improvments” , its a person who dont know
too much about system level debugging.
With respect, Dan
----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Monday, August 12, 2002 4:27 PM
Subject: [ntdev] Re: Very slow processing…
> Actually I believe that the problem is the communications link. Correct me
> if I’m wrong, but looks to me like Windbg is host-centric, hence the
> problem. SoftICE is target-centric, the host layer is just a terminal
> program, all of the processing takes place on the target and doesn’t need
to
> communicate to the host until the information is ready to be displayed.
And
> by the way, that’s one of the advantages of single-machine debugging,
> there’s no communications delay anywhere.
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Peter Viscarola [mailto:xxxxx@osr.com]
> Sent: Friday, August 09, 2002 4:14 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Very slow processing…
>
>
> “Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> >
> > Peter, in what case single stepping is slow ? Inquiring minds want to
> know.
> >
> >
>
> I’m specifically addressing the bag here… single-steps can often be
quite
> slow as a result of symbol-table lookups and such. Depends what you’re
> stepping IN to, OVER, or TO.
>
> P
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
Golly, Dan…
I was just making an objective technical point. No more. And you know what,
watch this space, we’re coming up with a new SoftICE and more, and many of
the stuff you’re complaining about will be available soon enough. But still:
About huge symbol tables: I thought we had fixed the huge symbol table issue
back on DriverStudio 2.6 ? But let me get back to my people and see. On that
line: it helps to have real bug reports from our users ! We don’t have a
crystal ball, and I feel slightly uncomfortable washing my dirty clothes in
public, specially before I had a chance to put them through my normal
firefighting pipeline.
About stacks: we know we have a couple of problems in this area. Still, are
we that much worse than our competition ? We’re working on this sort of
thing as we speak, and again, it would help to have actual bugs logged into
our database.
About FS driver development: SoftICE is a ring 0 debugger, not an OS
debugger. Our approach is to show information from inside the OS, but not to
really interact with it: we like to consider the debugging engine as being
OS-independent. Commands to handle FS drivers may be more adequate in a ring
3 component, which by definition is not SoftICE: we have the workbench to
host this kind of thing. Still, if you let me know what kind of commands you
need, I’ll try to oblige !
About deadlocks: we’re putting that kind of functionality in BoundsChecker -
SoftICE is a machine level debugger, not specifically an OS debugger. I
would like to pretend that the inner SoftICE debugging engine is, or should
be, OS independent. Although SoftICE has knowledge of Windows internals, it
is not supposed to be that integrated with the OS ! Yet we have commands
such as ksem, kevent and kmutex in SoftICE, what additional deadlock and
livelock functionality would you like to see ? I’ll be glad to oblige, if it
is within my power, and of course if I know what it is that people want to
see.
About Windbg extensions: First, let me remind you, Compuware Numega does not
develop Windbg extensions ! We put in support to somebody else’s facilities
as a courtesy to our users. SoftICE is a kernel level debugger, it operates
exclusively at ring 0. It cannot perfectly handle any extensions that
require ring 3 processing, because at that time the system is probably dead
anyway. So, we can kind of run ring 3 extensions from ring 0, but then, if
the original extension misbehaves or crashes in a way that is picked up by a
ring 3 exception handling mechanism, we can’t handle it: because the OS is
not operational at that point. That’s what I mean when I say SoftICE is a
ring 0 debugger ! All its functionality must work whether the OS is dead or
alive. We have some support for Ring 3 Extensions in the DriverWorkbench,
but right now it only applies to Crash Dump Files. I guess the message is,
SoftICE is a ring 0 debugger that happens to have access to the OS. It
cannot be a part of the OS ! Only the OS manufacturer can pull that trick.
About scripting language extensibility: again, SoftICE is a kernel side
debugger. When it runs, the machine is stopped, file systems and OS calls
are not available, windowing and display drivers are possibly dead, and in
some cases it takes a monochrome monitor to be able to even see any output.
SoftICE was not written to be driven by an application ! It’s a machine
level debugger that must offer full functionality regardless of how much of
the operating system is still alive.
About the Symbol Loader: we got pretty decent reviews by many users of our
new loader. It is a great improvement over what we had before. It is a 100%
GUI product, mind you, the effort put into writing it did not denigrate one
iota from the effort on the kernel side of the system.
About cosmetics: Dan, we came out with a major evolution of the whole system
when we released DriverStudio 2.5: it is now a fully distributed system,
with multiple hosts and multiple targets, which runs on any
Windows-supported network that implements TCP/IP. That’s not what I would
call cosmetics ! We run on TCP/IP over ethernet, we also run on TCP/IP over
Firewire if you have Windows XP. Have you tried it ? It rocks. I can remote
debug any machine on my local intranet without leaving my office, eh ?
That’s not what I’d call cosmetic either. I can remote setup my
BoundsChecker to trigger on any event I care to monitor, and pop up SoftICE
on the remote machine, and redirect to the host system at my office, so that
when I get in next morning I have a window with SoftICE popped up on the
remote machine - or machines - where errors have been found. Now, does that
help the individual consultant kernel dev working on his two machines at his
home office ? Obviously not. But think about all those development, QA and
Integration labs with tens of machines handling all kinds of development
issues, automated test, and what not: the evolution of the product into a
host/target system where targets are free of charge has been very well
received by many people. On that line, we have the Namespace Extension, you
can see all machines in your network, right click on any of them, and
control a remote SoftICE
A final word: we would really appreciate to hear from you what new
functionality you want to see in SoftICE, considering, of course, that it is
a ring 0 product. Let us know ! We make a point of listening to our users,
and we try our best, within our limitations, to oblige.
Alberto.
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Monday, August 12, 2002 9:23 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Very slow processing…
Ya Alberto, you are very right, unfortunately NTICE has a lot of other
issues, like inability to corectly parse hughe symbols tables from .PDB
generated with latest MS compilers, especially it cannot handle locals
correctly, it spits out wrong stack backtraces sometimes,
it ruins stack backtraces in crash dumps sometimes, because you may end
having NTICE hook functions into the stack, which cannot be correctly
backtraced because NTICE.SYS does not come with symbols and FPO data to help
for this, it lacks many usefull commands for FS driver developing, its a
pain in the ass to debug deadlocks or livelocks with NTICE.
Your hacked interface for using Windbg extensions works all the time, save
for the moments it doesnt work at all,
for many many commands all you get is a fault while processing the command,
you dont have a native mechanism for extending NTICE command set, using a
scripting language or a clear plugin interface with full access to base
NTICE functions.
Finally, your company seems much more interested to make minor cosmetic
improvements on NTICE, instead of focusing on real stuff who would help
developers. Its much more important to have an accurate debugger than having
“user defined” popup menus, workspaces in loader, and other minor things
like this. Frankly , since NuMega was acquired by Compuware, all I can see
is a constant quality drop and lack of pace into developing NTICE. I really
think you should focus on important things, donno who decide what the hell
will go into the next version of NTICE, but
judging after the last X versions “improvments” , its a person who dont know
too much about system level debugging.
With respect, Dan
----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Monday, August 12, 2002 4:27 PM
Subject: [ntdev] Re: Very slow processing…
> Actually I believe that the problem is the communications link. Correct me
> if I’m wrong, but looks to me like Windbg is host-centric, hence the
> problem. SoftICE is target-centric, the host layer is just a terminal
> program, all of the processing takes place on the target and doesn’t need
to
> communicate to the host until the information is ready to be displayed.
And
> by the way, that’s one of the advantages of single-machine debugging,
> there’s no communications delay anywhere.
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Peter Viscarola [mailto:xxxxx@osr.com]
> Sent: Friday, August 09, 2002 4:14 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Very slow processing…
>
>
> “Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> >
> > Peter, in what case single stepping is slow ? Inquiring minds want to
> know.
> >
> >
>
> I’m specifically addressing the bag here… single-steps can often be
quite
> slow as a result of symbol-table lookups and such. Depends what you’re
> stepping IN to, OVER, or TO.
>
> P
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
Alberto,
> and I feel slightly uncomfortable washing my dirty clothes in public,
specially before I had a chance to put them
> through my normal
I am very sorry. Please accept my apologies. Its indeed better to have those
mails in private. I seen that Chris wrote to me, I really apreciate it so
Ill bore him with more technical details. Again please accept my apolgies
for my lack of tact.
> About scripting language extensibility: again, SoftICE is a kernel side
> debugger.
Well , Im old enough in this area to be prefectly aware of how Softice
operates on Ia32, more than that, I have the pretention that I do understand
NTICE (and in general , of any system level debugger )mechanics good enough
to rewrite its core on my own. Call it arrognace if you want, but I can
assure you im not kidding.
I am not talking about having NTICE driven by a ring3 problem. Tough you can
simply either
A. Embed a interpretor into NTICE, and have NTICE load the scripts at boot
time, the very same way it loads
symbol files into a internal buffer.
B. Define a clear plugin interface, and load plugin kernel mode DLLs which
talk to NTICE interface through
classic PE exports . You can load a list of user define plug-ins at NTICE
init time very simple, and register them
with the debugger. Its perfectly possible to do this, if you guys are
willing to expose some of the NTICE internal routines and intenral
variables, or come with methods to access those varibales. I am perfectly
aware of the very
tight conditions in which such code would run, but if the user aint able to
write his own plugins to enhance the toy
then its his problem, you did the best.
> It cannot perfectly handle any extensions that require ring 3 processing.
I know. That why you should make a NTICE SDK, and not provide hacked
support into Windbg interface.
I could then rewrite the esential stuff I use from MS’s extensions to native
NTICE extensions. In fact, all those
Windbg extensions end talking to the debuggee through a very simple
interface, which you already must have
program it, given you have partial compatibility.
> About stacks. Still, are we that much worse than our competition ?
I cant judge how bad is NTICE here, with respect to competition. All I know
that for me a proper stack trace worths gold. I personally seen ppl on this
list hunting ghosts because they had a wrong backtrace, and the poor beeings
where not able to see its trashed. Windbg spits out much more clean
backtraces.
Lemme get back to Chris now .
Best regards, Dan
----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Monday, August 12, 2002 6:55 PM
Subject: [ntdev] Re: Very slow processing…
> Golly, Dan…
>
> I was just making an objective technical point. No more. And you know
what,
> watch this space, we’re coming up with a new SoftICE and more, and many of
> the stuff you’re complaining about will be available soon enough. But
still:
>
> About huge symbol tables: I thought we had fixed the huge symbol table
issue
> back on DriverStudio 2.6 ? But let me get back to my people and see. On
that
> line: it helps to have real bug reports from our users ! We don’t have a
> crystal ball, and I feel slightly uncomfortable washing my dirty clothes
in
> public, specially before I had a chance to put them through my normal
> firefighting pipeline.
>
> About stacks: we know we have a couple of problems in this area. Still,
are
> we that much worse than our competition ? We’re working on this sort of
> thing as we speak, and again, it would help to have actual bugs logged
into
> our database.
>
> About FS driver development: SoftICE is a ring 0 debugger, not an OS
> debugger. Our approach is to show information from inside the OS, but not
to
> really interact with it: we like to consider the debugging engine as being
> OS-independent. Commands to handle FS drivers may be more adequate in a
ring
> 3 component, which by definition is not SoftICE: we have the workbench to
> host this kind of thing. Still, if you let me know what kind of commands
you
> need, I’ll try to oblige !
>
> About deadlocks: we’re putting that kind of functionality in
BoundsChecker -
> SoftICE is a machine level debugger, not specifically an OS debugger. I
> would like to pretend that the inner SoftICE debugging engine is, or
should
> be, OS independent. Although SoftICE has knowledge of Windows internals,
it
> is not supposed to be that integrated with the OS ! Yet we have commands
> such as ksem, kevent and kmutex in SoftICE, what additional deadlock and
> livelock functionality would you like to see ? I’ll be glad to oblige, if
it
> is within my power, and of course if I know what it is that people want to
> see.
>
> About Windbg extensions: First, let me remind you, Compuware Numega does
not
> develop Windbg extensions ! We put in support to somebody else’s
facilities
> as a courtesy to our users. SoftICE is a kernel level debugger, it
operates
> exclusively at ring 0. It cannot perfectly handle any extensions that
> require ring 3 processing, because at that time the system is probably
dead
> anyway. So, we can kind of run ring 3 extensions from ring 0, but then, if
> the original extension misbehaves or crashes in a way that is picked up by
a
> ring 3 exception handling mechanism, we can’t handle it: because the OS is
> not operational at that point. That’s what I mean when I say SoftICE is a
> ring 0 debugger ! All its functionality must work whether the OS is dead
or
> alive. We have some support for Ring 3 Extensions in the DriverWorkbench,
> but right now it only applies to Crash Dump Files. I guess the message is,
> SoftICE is a ring 0 debugger that happens to have access to the OS. It
> cannot be a part of the OS ! Only the OS manufacturer can pull that trick.
>
> About scripting language extensibility: again, SoftICE is a kernel side
> debugger. When it runs, the machine is stopped, file systems and OS calls
> are not available, windowing and display drivers are possibly dead, and in
> some cases it takes a monochrome monitor to be able to even see any
output.
> SoftICE was not written to be driven by an application ! It’s a machine
> level debugger that must offer full functionality regardless of how much
of
> the operating system is still alive.
>
> About the Symbol Loader: we got pretty decent reviews by many users of our
> new loader. It is a great improvement over what we had before. It is a
100%
> GUI product, mind you, the effort put into writing it did not denigrate
one
> iota from the effort on the kernel side of the system.
>
> About cosmetics: Dan, we came out with a major evolution of the whole
system
> when we released DriverStudio 2.5: it is now a fully distributed system,
> with multiple hosts and multiple targets, which runs on any
> Windows-supported network that implements TCP/IP. That’s not what I would
> call cosmetics ! We run on TCP/IP over ethernet, we also run on TCP/IP
over
> Firewire if you have Windows XP. Have you tried it ? It rocks. I can
remote
> debug any machine on my local intranet without leaving my office, eh ?
> That’s not what I’d call cosmetic either. I can remote setup my
> BoundsChecker to trigger on any event I care to monitor, and pop up
SoftICE
> on the remote machine, and redirect to the host system at my office, so
that
> when I get in next morning I have a window with SoftICE popped up on the
> remote machine - or machines - where errors have been found. Now, does
that
> help the individual consultant kernel dev working on his two machines at
his
> home office ? Obviously not. But think about all those development, QA and
> Integration labs with tens of machines handling all kinds of development
> issues, automated test, and what not: the evolution of the product into a
> host/target system where targets are free of charge has been very well
> received by many people. On that line, we have the Namespace Extension,
you
> can see all machines in your network, right click on any of them, and
> control a remote SoftICE
>
> A final word: we would really appreciate to hear from you what new
> functionality you want to see in SoftICE, considering, of course, that it
is
> a ring 0 product. Let us know ! We make a point of listening to our users,
> and we try our best, within our limitations, to oblige.
>
>
> Alberto.
>
>
>
>
> -----Original Message-----
> From: Dan Partelly [mailto:xxxxx@rdsor.ro]
> Sent: Monday, August 12, 2002 9:23 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Very slow processing…
>
>
> Ya Alberto, you are very right, unfortunately NTICE has a lot of other
> issues, like inability to corectly parse hughe symbols tables from .PDB
> generated with latest MS compilers, especially it cannot handle locals
> correctly, it spits out wrong stack backtraces sometimes,
> it ruins stack backtraces in crash dumps sometimes, because you may end
> having NTICE hook functions into the stack, which cannot be correctly
> backtraced because NTICE.SYS does not come with symbols and FPO data to
help
> for this, it lacks many usefull commands for FS driver developing, its a
> pain in the ass to debug deadlocks or livelocks with NTICE.
>
> Your hacked interface for using Windbg extensions works all the time, save
> for the moments it doesnt work at all,
> for many many commands all you get is a fault while processing the
command,
> you dont have a native mechanism for extending NTICE command set, using a
> scripting language or a clear plugin interface with full access to base
> NTICE functions.
>
> Finally, your company seems much more interested to make minor cosmetic
> improvements on NTICE, instead of focusing on real stuff who would help
> developers. Its much more important to have an accurate debugger than
having
> “user defined” popup menus, workspaces in loader, and other minor things
> like this. Frankly , since NuMega was acquired by Compuware, all I can
see
> is a constant quality drop and lack of pace into developing NTICE. I
really
> think you should focus on important things, donno who decide what the hell
> will go into the next version of NTICE, but
> judging after the last X versions “improvments” , its a person who dont
know
> too much about system level debugging.
>
> With respect, Dan
>
>
>
>
> ----- Original Message -----
> From: “Moreira, Alberto”
> To: “NT Developers Interest List”
> Sent: Monday, August 12, 2002 4:27 PM
> Subject: [ntdev] Re: Very slow processing…
>
>
> > Actually I believe that the problem is the communications link. Correct
me
> > if I’m wrong, but looks to me like Windbg is host-centric, hence the
> > problem. SoftICE is target-centric, the host layer is just a terminal
> > program, all of the processing takes place on the target and doesn’t
need
> to
> > communicate to the host until the information is ready to be displayed.
> And
> > by the way, that’s one of the advantages of single-machine debugging,
> > there’s no communications delay anywhere.
> >
> > Alberto.
> >
> >
> >
> > -----Original Message-----
> > From: Peter Viscarola [mailto:xxxxx@osr.com]
> > Sent: Friday, August 09, 2002 4:14 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Very slow processing…
> >
> >
> > “Moreira, Alberto” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > Peter, in what case single stepping is slow ? Inquiring minds want to
> > know.
> > >
> > >
> >
> > I’m specifically addressing the bag here… single-steps can often be
> quite
> > slow as a result of symbol-table lookups and such. Depends what you’re
> > stepping IN to, OVER, or TO.
> >
> > P
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@compuware.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only.
It
> > contains information that may be confidential. Unless you are the named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>