I would trace some driver source code step by step.
Windbg seems to be the best tool for this now.
It needs to setup two machines for kernel debugging.
NULL modem is inconvenient for NB since no COM port.
Besides, the speed is slow for source level trace through NULL modem.
I hope I can find a easy setup way for kernel driver debugging.
I want to know what kind of connection cable most driver developer use.
What’s your favor connection setup way?
Best Regards
Jack Huang
It is possible that most people on this list in fact use COM; I really
don’t know. In any case, as you have already indicated that you don’t
wish to use COM (I agree with you here), then basically everyone else
uses 1394. I can’t say that I personally know anyone who actually uses
USB daily, and the cables are hard to find and expensive. The big thing
with 1394 and WinDbg is getting a 1394 card that WinDbg plays well with.
Cards based on the TI chipset fit this bill, but figuring out what card
uses which chipset from packaging or websites is very difficult. In my
experience, most PCI based 1394 cards will work, but there are
definitely some which do not, and I never gotten anything to work over
PCMCIA or whatever it is called now, but I’ve only tried a couple of
times. The long and short, for me, at least, is that I try some
amazingly cheap/whatever is convenient 1394 PCI card, and if that
doesn’t work, pony up with something Adaptec. The later are
outrageously overpriced, but I don’t think that I’ve ever had one that
hasn’t worked, and trying to figure out the chipsets of these things
drives me out of my mind. I haven’t purchased one in a couple of years,
and there are many on this lists who have researched this more than I
have and certainly can give you better advice, but I think what I said
above will work in almost all cases, albeit not inexpensively.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of huangjj
Sent: Friday, June 22, 2007 02:13
To: Kernel Debugging Interest List
Subject: [windbg] What’s the common connection way using windbg for
source code tracing?
I would trace some driver source code step by step.
Windbg seems to be the best tool for this now.
It needs to setup two machines for kernel debugging.
NULL modem is inconvenient for NB since no COM port.
Besides, the speed is slow for source level trace through NULL modem.
I hope I can find a easy setup way for kernel driver debugging.
I want to know what kind of connection cable most driver developer use.
What’s your favor connection setup way?
Best Regards
Jack Huang
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
My experience is that it is useful to have a null modem COM cable hooked up
as well as 1394. I’ve found situations when swapping to com port has fixed
bogus debugging problems that happen using 1394. But this may be because I
was developing a 1394 driver so the two occasonally confused each other!
Either way, the COM port method seemed to require less of the system to work
than 1394 for when things are really falling to pieces. Also it avoids all
that “which 1394 card?” issue. And when you find one that does work, does it
work all the time? The whole black magic of why some work and others don’t
is a bit scary when you just want to get on with debugging…
BTW I agree about the adaptec - they seem both expensive and ok, but most of
the cheap ones also have not given me a problem (apart from the “who knows”
issues above).
I did not find 1394 all that much faster either - maybe I was not using the
data hungry parts of windbg - but with an MP target machine it all seems
extremely slow.
M
----- Original Message -----
From: Martin O’Brien
To: Kernel Debugging Interest List
Sent: Friday, June 22, 2007 11:25 AM
Subject: RE: [windbg] What’s the common connection way using windbg for
source code tracing?
It is possible that most people on this list in fact use COM; I really
don’t know. In any case, as you have already indicated that you don’t
wish to use COM (I agree with you here), then basically everyone else
uses 1394. I can’t say that I personally know anyone who actually uses
USB daily, and the cables are hard to find and expensive. The big thing
with 1394 and WinDbg is getting a 1394 card that WinDbg plays well with.
Cards based on the TI chipset fit this bill, but figuring out what card
uses which chipset from packaging or websites is very difficult. In my
experience, most PCI based 1394 cards will work, but there are
definitely some which do not, and I never gotten anything to work over
PCMCIA or whatever it is called now, but I’ve only tried a couple of
times. The long and short, for me, at least, is that I try some
amazingly cheap/whatever is convenient 1394 PCI card, and if that
doesn’t work, pony up with something Adaptec. The later are
outrageously overpriced, but I don’t think that I’ve ever had one that
hasn’t worked, and trying to figure out the chipsets of these things
drives me out of my mind. I haven’t purchased one in a couple of years,
and there are many on this lists who have researched this more than I
have and certainly can give you better advice, but I think what I said
above will work in almost all cases, albeit not inexpensively.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of huangjj
Sent: Friday, June 22, 2007 02:13
To: Kernel Debugging Interest List
Subject: [windbg] What’s the common connection way using windbg for
source code tracing?
I would trace some driver source code step by step.
Windbg seems to be the best tool for this now.
It needs to setup two machines for kernel debugging.
NULL modem is inconvenient for NB since no COM port.
Besides, the speed is slow for source level trace through NULL modem.
I hope I can find a easy setup way for kernel driver debugging.
I want to know what kind of connection cable most driver developer use.
What’s your favor connection setup way?
Best Regards
Jack Huang
You are currently subscribed to windbg as: xxxxx@evitechnology.com
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
Funny, I have had multiple customers where the solution for getting 1394 to
work was rip out all the adaptec cards. I have had more trouble with them
than any other 1394. The most reliable is the stuff you can buy from OSR.
Also, be aware that many 1394 cards get flaky for WinDBG if things get
warm, my lab can get on the warm side and zap there goes the 1394 debug.
I agree with the com as a backup. Now if Microsoft would just get a clue,
since Vista and Server 2008 only allow one debug link type on the boot
selections! They slipped this in the last beta release of Vista, so most
of us did not get a chance to complain!
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Mike Kemp” wrote in message news:xxxxx@windbg…
> My experience is that it is useful to have a null modem COM cable hooked
> up as well as 1394. I’ve found situations when swapping to com port has
> fixed bogus debugging problems that happen using 1394. But this may be
> because I was developing a 1394 driver so the two occasonally confused
> each other!
>
> Either way, the COM port method seemed to require less of the system to
> work than 1394 for when things are really falling to pieces. Also it
> avoids all that “which 1394 card?” issue. And when you find one that does
> work, does it work all the time? The whole black magic of why some work
> and others don’t is a bit scary when you just want to get on with
> debugging…
>
> BTW I agree about the adaptec - they seem both expensive and ok, but most
> of the cheap ones also have not given me a problem (apart from the “who
> knows” issues above).
>
> I did not find 1394 all that much faster either - maybe I was not using
> the data hungry parts of windbg - but with an MP target machine it all
> seems extremely slow.
>
> M
>
> ----- Original Message -----
> From: Martin O’Brien
> To: Kernel Debugging Interest List
> Sent: Friday, June 22, 2007 11:25 AM
> Subject: RE: [windbg] What’s the common connection way using windbg for
> source code tracing?
>
>
> It is possible that most people on this list in fact use COM; I really
> don’t know. In any case, as you have already indicated that you don’t
> wish to use COM (I agree with you here), then basically everyone else
> uses 1394. I can’t say that I personally know anyone who actually uses
> USB daily, and the cables are hard to find and expensive. The big thing
> with 1394 and WinDbg is getting a 1394 card that WinDbg plays well with.
> Cards based on the TI chipset fit this bill, but figuring out what card
> uses which chipset from packaging or websites is very difficult. In my
> experience, most PCI based 1394 cards will work, but there are
> definitely some which do not, and I never gotten anything to work over
> PCMCIA or whatever it is called now, but I’ve only tried a couple of
> times. The long and short, for me, at least, is that I try some
> amazingly cheap/whatever is convenient 1394 PCI card, and if that
> doesn’t work, pony up with something Adaptec. The later are
> outrageously overpriced, but I don’t think that I’ve ever had one that
> hasn’t worked, and trying to figure out the chipsets of these things
> drives me out of my mind. I haven’t purchased one in a couple of years,
> and there are many on this lists who have researched this more than I
> have and certainly can give you better advice, but I think what I said
> above will work in almost all cases, albeit not inexpensively.
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of huangjj
> Sent: Friday, June 22, 2007 02:13
> To: Kernel Debugging Interest List
> Subject: [windbg] What’s the common connection way using windbg for
> source code tracing?
>
> I would trace some driver source code step by step.
> Windbg seems to be the best tool for this now.
> It needs to setup two machines for kernel debugging.
> NULL modem is inconvenient for NB since no COM port.
> Besides, the speed is slow for source level trace through NULL modem.
> I hope I can find a easy setup way for kernel driver debugging.
> I want to know what kind of connection cable most driver developer use.
> What’s your favor connection setup way?
>
> Best Regards
> Jack Huang
>
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@evitechnology.com
> 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
>
Sometimes 1394 and WinDbg feels like a conspiracy. Who knows. My
experience with 1394 is maybe seven cards total, so I really can’t say
that I’ve researched the problem thoroughly.
About the boot selections. Are you saying that two different
configurations can’t have different transport settings? If so, that
does indeed suck.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, June 22, 2007 08:23
To: Kernel Debugging Interest List
Subject: Re:[windbg] What’s the common connection way using windbg for
source code tracing?
Funny, I have had multiple customers where the solution for getting 1394
to
work was rip out all the adaptec cards. I have had more trouble with
them
than any other 1394. The most reliable is the stuff you can buy from
OSR.
Also, be aware that many 1394 cards get flaky for WinDBG if things get
warm, my lab can get on the warm side and zap there goes the 1394 debug.
I agree with the com as a backup. Now if Microsoft would just get a
clue,
since Vista and Server 2008 only allow one debug link type on the boot
selections! They slipped this in the last beta release of Vista, so
most
of us did not get a chance to complain!
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“Mike Kemp” wrote in message news:xxxxx@windbg…
> My experience is that it is useful to have a null modem COM cable
hooked
> up as well as 1394. I’ve found situations when swapping to com port
has
> fixed bogus debugging problems that happen using 1394. But this may be
> because I was developing a 1394 driver so the two occasonally confused
> each other!
>
> Either way, the COM port method seemed to require less of the system
to
> work than 1394 for when things are really falling to pieces. Also it
> avoids all that “which 1394 card?” issue. And when you find one that
does
> work, does it work all the time? The whole black magic of why some
work
> and others don’t is a bit scary when you just want to get on with
> debugging…
>
> BTW I agree about the adaptec - they seem both expensive and ok, but
most
> of the cheap ones also have not given me a problem (apart from the
“who
> knows” issues above).
>
> I did not find 1394 all that much faster either - maybe I was not
using
> the data hungry parts of windbg - but with an MP target machine it all
> seems extremely slow.
>
> M
>
> ----- Original Message -----
> From: Martin O’Brien
> To: Kernel Debugging Interest List
> Sent: Friday, June 22, 2007 11:25 AM
> Subject: RE: [windbg] What’s the common connection way using windbg
for
> source code tracing?
>
>
> It is possible that most people on this list in fact use COM; I really
> don’t know. In any case, as you have already indicated that you don’t
> wish to use COM (I agree with you here), then basically everyone else
> uses 1394. I can’t say that I personally know anyone who actually
uses
> USB daily, and the cables are hard to find and expensive. The big
thing
> with 1394 and WinDbg is getting a 1394 card that WinDbg plays well
with.
> Cards based on the TI chipset fit this bill, but figuring out what
card
> uses which chipset from packaging or websites is very difficult. In
my
> experience, most PCI based 1394 cards will work, but there are
> definitely some which do not, and I never gotten anything to work over
> PCMCIA or whatever it is called now, but I’ve only tried a couple of
> times. The long and short, for me, at least, is that I try some
> amazingly cheap/whatever is convenient 1394 PCI card, and if that
> doesn’t work, pony up with something Adaptec. The later are
> outrageously overpriced, but I don’t think that I’ve ever had one that
> hasn’t worked, and trying to figure out the chipsets of these things
> drives me out of my mind. I haven’t purchased one in a couple of
years,
> and there are many on this lists who have researched this more than I
> have and certainly can give you better advice, but I think what I said
> above will work in almost all cases, albeit not inexpensively.
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of huangjj
> Sent: Friday, June 22, 2007 02:13
> To: Kernel Debugging Interest List
> Subject: [windbg] What’s the common connection way using windbg for
> source code tracing?
>
> I would trace some driver source code step by step.
> Windbg seems to be the best tool for this now.
> It needs to setup two machines for kernel debugging.
> NULL modem is inconvenient for NB since no COM port.
> Besides, the speed is slow for source level trace through NULL modem.
> I hope I can find a easy setup way for kernel driver debugging.
> I want to know what kind of connection cable most driver developer
use.
> What’s your favor connection setup way?
>
> Best Regards
> Jack Huang
>
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@evitechnology.com
> 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
>
—
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
About the boot selections. Are you saying that two different
configurations can’t have different transport settings? If so, that
does indeed suck.
That is exactly what I mean, Microsoft in their ultimate wisdom, made
debugger settings global to the machine with only an option to indicate
whether or not to use the debugger setting per boot selection. They
slipped this in on the last beta before release and have responeded to my
bug reports as “Its not a bug its a feature”. Every machine in my lab has,
serial and 1394 cables, and boot selections for debugging over either for
every OS prior to Vista. This is one of many reasons I charge a lot extra
if a customer wants a Vista driver from me.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
I would ask why they would do this, but, given that it all a part of the
big bcdedit picture, what’s the point - it all sucks.
Good info,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Friday, June 22, 2007 08:48
To: Kernel Debugging Interest List
Subject: Re:[windbg] What’s the common connection way using windbg for
source code tracing?
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
About the boot selections. Are you saying that two different
configurations can’t have different transport settings? If so, that
does indeed suck.
That is exactly what I mean, Microsoft in their ultimate wisdom, made
debugger settings global to the machine with only an option to indicate
whether or not to use the debugger setting per boot selection. They
slipped this in on the last beta before release and have responeded to
my
bug reports as “Its not a bug its a feature”. Every machine in my lab
has,
serial and 1394 cables, and boot selections for debugging over either
for
every OS prior to Vista. This is one of many reasons I charge a lot
extra
if a customer wants a Vista driver from me.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
>Also, be aware that many 1394 cards get flaky for WinDBG if things get
warm, my lab can get on the warm side and zap there goes the 1394 debug.
Hadn’t heard this one. Just the sort of variables we need when debugging. Glad to hear MS has made it more difficult with Vista - don’t want to risk any 3rd party driver getting anywhere near reliable! Still maybe a set of carefully chosen 1394 cards could be the basis of a cheap digital thermometer for the home weather station enthusiast…
M
“Mike Kemp” wrote in message news:xxxxx@windbg…
[snip]
> I did not find 1394 all that much faster either - maybe I was not using
> the data hungry parts of windbg - but with an MP target machine it all
> seems extremely slow.
This has been discussed at length on this very forum and on
microsoft.public.windbg. 1394 on a single CPU is very fast. Much faster
than a COM port. And, as long as you don’t actually do anything, 1394 on
SMP is quite fast. As soon as you do anything at all, such as a DbgPrint()
or single step, the kernel aquires a global lock, stops all your processors,
which is a slow activity, and then does the action. Essentially, anything
that the debugger does stops the machine in its tracks for the duration of
the debugger action. Much slower than on a single CPU.
For stuff that doesn’t really depend on MP testing, such as your initial
development of your construction and destruction, if you like spew, /ONECPU
is your friend. Once I have that stuff done, so that I can get to the
asynchronous IO part, I disable the spew and then do everything with as many
CPUs as I have available.
Phil
–
Philip D. Barila
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
thx, I use /onecpu from time to time, but since I guess in most current
drivers many bugs are likely to be related to multiple processors, the idea
of having to disable the MP just to get the tools to work in a timely manner
seems a little strange. So my experience remains that COM isn’t much slower
than 1394 and when you consider the time spent wondering whether to turn on
the air-con to fix the bug (as Don needs to do) you seriously wonder whether
COM is in fact the only current viable debug link.
And, as long as you don’t actually do anything, 1394 on SMP is quite fast.
Yeah - doing nothing it’s alright.
BTW The number of times the MP speed issue has been discussed tells us, if
anything, how much anyone at MS cares! If my customers had to jump through
so many hoops to make things work I’d be doing nothing much more.
M
----- Original Message -----
From: Philip D. Barila
Newsgroups: windbg
To: Kernel Debugging Interest List
Sent: Friday, June 22, 2007 4:51 PM
Subject: Re:[windbg] What’s the common connection way using windbg for
source code tracing?
“Mike Kemp” wrote in message news:xxxxx@windbg…
[snip]
> I did not find 1394 all that much faster either - maybe I was not using
> the data hungry parts of windbg - but with an MP target machine it all
> seems extremely slow.
This has been discussed at length on this very forum and on
microsoft.public.windbg. 1394 on a single CPU is very fast. Much faster
than a COM port. And, as long as you don’t actually do anything, 1394 on
SMP is quite fast. As soon as you do anything at all, such as a DbgPrint()
or single step, the kernel aquires a global lock, stops all your processors,
which is a slow activity, and then does the action. Essentially, anything
that the debugger does stops the machine in its tracks for the duration of
the debugger action. Much slower than on a single CPU.
For stuff that doesn’t really depend on MP testing, such as your initial
development of your construction and destruction, if you like spew, /ONECPU
is your friend. Once I have that stuff done, so that I can get to the
asynchronous IO part, I disable the spew and then do everything with as many
CPUs as I have available.
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@sintefex.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
huangjj wrote:
I would trace some driver source code step by step.
Windbg seems to be the best tool for this now.
It needs to setup two machines for kernel debugging.
NULL modem is inconvenient for NB since no COM port.
Besides, the speed is slow for source level trace through NULL modem.
Most modern COM ports can run at 115,200 baud. Windbg is not too bad at
that speed, although 1394 is still better.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“Don Burn” wrote:
> About the boot selections. Are you saying that two different
> configurations can’t have different transport settings? If so, that
> does indeed suck.That is exactly what I mean, Microsoft in their ultimate wisdom, made
debugger settings global to the machine with only an option to indicate
whether or not to use the debugger setting per boot selection. They
slipped this in on the last beta before release and have responeded to my
bug reports as “Its not a bug its a feature”. Every machine in my lab
has, serial and 1394 cables, and boot selections for debugging over either
for every OS prior to Vista. This is one of many reasons I charge a lot
extra if a customer wants a Vista driver from me.
Bcdedit /dbgsettings options are in fact global to the machine, but I
thought it was possible to override them for each boot entry using
bcdedit /set:
http://groups.google.com/group/microsoft.public.windbg/msg/5c47cb52c9a56d04?dmode=source&hl=en
Are you sure this doesn’t work?
–
This posting is provided “AS IS” with no warranties, and confers no
rights.
Thanks for all your answers!
I also used COM port for kernel debugger before.
However, most NBs don’t contain COM port interface now.
I just wonder how to debug on NB if no COM port.
COM port may disappear in the future new PC.
According to your discuss, 1394 seems to be the acceptable solution now
if COM port is not present.
It may be also good if usb to serial device can be used to replace COM port.
However, I don’t think it can work…
Best Regards
Jack Huang
“Tim Roberts” …
> huangjj wrote:
>> I would trace some driver source code step by step.
>> Windbg seems to be the best tool for this now.
>> It needs to setup two machines for kernel debugging.
>> NULL modem is inconvenient for NB since no COM port.
>> Besides, the speed is slow for source level trace through NULL modem.
>>
>
> Most modern COM ports can run at 115,200 baud. Windbg is not too bad at
> that speed, although 1394 is still better.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
By the way, do you often use source level debug (step by step) when you
develop a new driver?
“huangjj” …
> Thanks for all your answers!
> I also used COM port for kernel debugger before.
> However, most NBs don’t contain COM port interface now.
> I just wonder how to debug on NB if no COM port.
> COM port may disappear in the future new PC.
>
> According to your discuss, 1394 seems to be the acceptable solution now
> if COM port is not present.
>
> It may be also good if usb to serial device can be used to replace COM
> port.
> However, I don’t think it can work…
>
> Best Regards
> Jack Huang
>
> “Tim Roberts” …
>> huangjj wrote:
>>> I would trace some driver source code step by step.
>>> Windbg seems to be the best tool for this now.
>>> It needs to setup two machines for kernel debugging.
>>> NULL modem is inconvenient for NB since no COM port.
>>> Besides, the speed is slow for source level trace through NULL modem.
>>>
>>
>> Most modern COM ports can run at 115,200 baud. Windbg is not too bad at
>> that speed, although 1394 is still better.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
>
>
“Pavel Lebedinsky” wrote in message
news:xxxxx@windbg…
> Bcdedit /dbgsettings options are in fact global to the machine, but I
> thought it was possible to override them for each boot entry using
> bcdedit /set:
>
> http://groups.google.com/group/microsoft.public.windbg/msg/5c47cb52c9a56d04?dmode=source&hl=en
>
I tried this when it was posted, it did not work for me. That does not
mean there is not a way, but everything including the new document on
BCDedit
http://www.microsoft.com/whdc/system/platform/firmware/bcdedit_reff.mspx
seems to indicate this is now impossible.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
USB serial devices do not work on the test machine. I use the debugger for
every driver I develop and typically for any code that is challenging step
through it to see that it is doing what I designed it to do.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
“huangjj” wrote in message news:xxxxx@windbg…
> By the way, do you often use source level debug (step by step) when you
> develop a new driver?
>
> “huangjj” …
>> Thanks for all your answers!
>> I also used COM port for kernel debugger before.
>> However, most NBs don’t contain COM port interface now.
>> I just wonder how to debug on NB if no COM port.
>> COM port may disappear in the future new PC.
>>
>> According to your discuss, 1394 seems to be the acceptable solution now
>> if COM port is not present.
>>
>> It may be also good if usb to serial device can be used to replace COM
>> port.
>> However, I don’t think it can work…
>>
>> Best Regards
>> Jack Huang
>>
>> “Tim Roberts” …
>>> huangjj wrote:
>>>> I would trace some driver source code step by step.
>>>> Windbg seems to be the best tool for this now.
>>>> It needs to setup two machines for kernel debugging.
>>>> NULL modem is inconvenient for NB since no COM port.
>>>> Besides, the speed is slow for source level trace through NULL modem.
>>>>
>>>
>>> Most modern COM ports can run at 115,200 baud. Windbg is not too bad
>>> at
>>> that speed, although 1394 is still better.
>>>
>>> –
>>> Tim Roberts, xxxxx@probo.com
>>> Providenza & Boekelheide, Inc.
>>>
>>>
>>
>>
>>
>
>
>
They don’t work. You need a real UART.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of huangjj
Sent: Saturday, June 23, 2007 03:26
To: Kernel Debugging Interest List
Subject: Re:[windbg] What’s the common connection way using windbg for
source code tracing?
Thanks for all your answers!
I also used COM port for kernel debugger before.
However, most NBs don’t contain COM port interface now.
I just wonder how to debug on NB if no COM port.
COM port may disappear in the future new PC.
According to your discuss, 1394 seems to be the acceptable solution now
if COM port is not present.
It may be also good if usb to serial device can be used to replace COM
port.
However, I don’t think it can work…
Best Regards
Jack Huang
“Tim Roberts” …
> huangjj wrote:
>> I would trace some driver source code step by step.
>> Windbg seems to be the best tool for this now.
>> It needs to setup two machines for kernel debugging.
>> NULL modem is inconvenient for NB since no COM port.
>> Besides, the speed is slow for source level trace through NULL modem.
>>
>
> Most modern COM ports can run at 115,200 baud. Windbg is not too bad
at
> that speed, although 1394 is still better.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
—
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I just tried this, and it works on Longhorn Beta 3 (6001-x64-chk). I
created one bcd entry for serial and one for 1394 channel 2, in addition
to the 1394 channel 1 I normally use, and all work. I don’t normally
use serial (never really, now that you don’t need it for boot debugging
anymore), and I don’t have on Vista targets at this point, and probably
never will again as long as the checked builds remain unbearable under
WinDbg, so maybe it works only now, in beta. I don’t know. The other
thing is that I usually don’t use /dbgsettings, so I tried setting it
only after all the overrides were already set, if that matters.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel Lebedinsky
Sent: Saturday, June 23, 2007 02:07
To: Kernel Debugging Interest List
Subject: Re:[windbg] What’s the common connection way using windbg for
source code tracing?
“Don Burn” wrote:
> About the boot selections. Are you saying that two different
> configurations can’t have different transport settings? If so, that
> does indeed suck.That is exactly what I mean, Microsoft in their ultimate wisdom, made
debugger settings global to the machine with only an option to
indicate
whether or not to use the debugger setting per boot selection. They
slipped this in on the last beta before release and have responeded to
my
bug reports as “Its not a bug its a feature”. Every machine in my lab
has, serial and 1394 cables, and boot selections for debugging over
either
for every OS prior to Vista. This is one of many reasons I charge a
lot
extra if a customer wants a Vista driver from me.
Bcdedit /dbgsettings options are in fact global to the machine, but I
thought it was possible to override them for each boot entry using
bcdedit /set:
http://groups.google.com/group/microsoft.public.windbg/msg/5c47cb52c9a56
d04?dmode=source&hl=en
Are you sure this doesn’t work?
–
This posting is provided “AS IS” with no warranties, and confers no
rights.
You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
“Don Burn” wrote:
> Bcdedit /dbgsettings options are in fact global to the machine, but I
> thought it was possible to override them for each boot entry using
> bcdedit /set:I tried this when it was posted, it did not work for me. That does not
mean there is not a way, but everything including the new document on
BCDedit
http://www.microsoft.com/whdc/system/platform/firmware/bcdedit_reff.mspx
seems to indicate this is now impossible.
This document actually mentions per-boot-entry debug parameters
like DEBUGTYPE (see the table under “Boot Applications”). Even
though it doesn’t talk about them in detail, I take that as a sign that
these parameters are supported (and as Martin mentioned, they do
work, at least in LH/SP1).
–
This posting is provided “AS IS” with no warranties, and confers no
rights.