I am attempting to debug a target running win7 64bit with kd via 1394. My debugger host is running XP (32 bit). This should just work, right?
I edited the boot options on the win7 target to output to 1394 channel 3. bcdedit and msconfig both confirm that these options are set correctly. And in the windbg window on the host, after starting kd with these options it shows “Using 1394 for debugging
Checking 1394 debug driver version.
Opened \.\DBG1394_INSTANCE03
Timer Resolution set to 976 usec.”
So everything should be matched up. But when I reboot the target, nothing comes up on my host windbg window. And when I select debug/break, I get the message: “Wrote 0 of 1 bytes of the breakin packet.
Failed to write breakin packet to target. Win32 error 0n2
WARNING: The HOST cannot communicate with the TARGET!”
I was originally using windbg version 6.11.1.404 on the host. When I ran into this issue, I upgraded to the latest, 6.12.0002.633, but got the same results.
Does the 1394 controller show as unavailable on the target machine when it’s booted after setting bcdedit /debug on ?
S
-----Original Message-----
From: xxxxx@yahoo.com Sent: Monday, March 22, 2010 12:13 To: Windows System Software Devs Interest List Subject: [ntdev] Problem debugging Win7 64bit target
I am attempting to debug a target running win7 64bit with kd via 1394. My debugger host is running XP (32 bit). This should just work, right?
I edited the boot options on the win7 target to output to 1394 channel 3. bcdedit and msconfig both confirm that these options are set correctly. And in the windbg window on the host, after starting kd with these options it shows “Using 1394 for debugging Checking 1394 debug driver version. Opened \.\DBG1394_INSTANCE03 Timer Resolution set to 976 usec.”
So everything should be matched up. But when I reboot the target, nothing comes up on my host windbg window. And when I select debug/break, I get the message: “Wrote 0 of 1 bytes of the breakin packet. Failed to write breakin packet to target. Win32 error 0n2 WARNING: The HOST cannot communicate with the TARGET!”
I was originally using windbg version 6.11.1.404 on the host. When I ran into this issue, I upgraded to the latest, 6.12.0002.633, but got the same results.
Thanks for the response. I’m not sure what you mean by “unavailable?” on the target? When I look in device manager, the host controller entry shows device is enabled and working properly.
Did you have a version of windbg older than 6.11.1.404 installed previously? If so, it’s possible that the new kd 1394 drivers that came with 6.11.1.404 didn’t install correctly. If this seems like a possibility, take a look at the ‘relnotes.txt’ file in the root of your windbg installtion (6.12.2.633 will be fine).
Thanks for the response. Alas, no, that is not the problem.
Googling turned up similar issues posted, but found no solutions, except for the guy who said he tried a new cable, and that seemed to fix it. Maybe my cable isn’t good enough, but it worked fine for debugging when the target was XP…
The 1394 controller shouldn’t show as enabled if you have it reserved for kernel debugging (on the target).
Are you sure that you also did bcdedit /set debug on in addition to configuring the dbgsettings portion?
S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, March 22, 2010 1:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Problem debugging Win7 64bit target
Thanks for the response. I’m not sure what you mean by “unavailable?” on the target? When I look in device manager, the host controller entry shows device is enabled and working properly.
Okay, so I figured, let me try null-modem connection, surely that will work. But it doesn’t! And, more wierdness – if debug is enabled, COM1 does not show up in device manager even if debug is set to output to 1394.
Update: I did a fresh clean install of windows 7 on the target. And viola, I can debug over either a 1394 or rs232 connection. I hadn’t done too much to the machine before trying kernel debugging – the only thing I can think of is possibly the antivirus software I had installed (symantec endpoint) was to blame.
Symantec Endpoint is very intrusive. I did consulting for one company that
used it throughout their organization.
The company was developing software for internal use. It required a
monumental effort to convince the company IT department (controllers of the
Symantec software…) that the software that their own company was
developing should be allow to run on their company’s computers.
From: Sent: Tuesday, March 23, 2010 11:46 AM To: “Windows System Software Devs Interest List” Subject: RE:[ntdev] Problem debugging Win7 64bit target
> Update: I did a fresh clean install of windows 7 on the target. And > viola, I can debug over either a 1394 or rs232 connection. I hadn’t done > too much to the machine before trying kernel debugging – the only thing I > can think of is possibly the antivirus software I had installed (symantec > endpoint) was to blame. > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Symantec has problems. I dumped them for both AV and disk imaging a few
years ago. Their AV product was blocking Microsoft Update from working, and
their imaging software I was using for a barebones restore (Ghost) hosed the
boot sector of the disk I was restoring. I’ve also enabled Verifier on their
drivers a few times. That convinced me that I never want Symantec on any of
my systems, nor will I recommend them.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Tuesday, March 23, 2010 10:55 AM
To: Windows System Software Devs Interest List
Subject: Re: RE:[ntdev] Problem debugging Win7 64bit target
Symantec Endpoint is very intrusive. I did consulting for one company that
used it throughout their organization.
The company was developing software for internal use. It required a
monumental effort to convince the company IT department (controllers of the
Symantec software…) that the software that their own company was
developing should be allow to run on their company’s computers.
From: Sent: Tuesday, March 23, 2010 11:46 AM To: “Windows System Software Devs Interest List” Subject: RE:[ntdev] Problem debugging Win7 64bit target
> Update: I did a fresh clean install of windows 7 on the target. And > viola, I can debug over either a 1394 or rs232 connection. I hadn’t done > too much to the machine before trying kernel debugging – the only thing I
> can think of is possibly the antivirus software I had installed (symantec > endpoint) was to blame. > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
In my experience using a win7 debug host for 1394 debugging connections to
*any* version windows target is more reliable than using a host with an
earlier rev os.
In this case it does not seem to be relevant.
Mark Roddy
On Tue, Mar 23, 2010 at 12:41 PM, Gary G. Little wrote:
> Symantec has problems. I dumped them for both AV and disk imaging a few > years ago. Their AV product was blocking Microsoft Update from working, and > their imaging software I was using for a barebones restore (Ghost) hosed > the > boot sector of the disk I was restoring. I’ve also enabled Verifier on > their > drivers a few times. That convinced me that I never want Symantec on any of > my systems, nor will I recommend them. > > Gary G. Little > H (952) 223-1349 > C (952) 454-4629 > xxxxx@comcast.net > > > > -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine > Sent: Tuesday, March 23, 2010 10:55 AM > To: Windows System Software Devs Interest List > Subject: Re: RE:[ntdev] Problem debugging Win7 64bit target > > Symantec Endpoint is very intrusive. I did consulting for one company that > used it throughout their organization. > > The company was developing software for internal use. It required a > monumental effort to convince the company IT department (controllers of the > Symantec software…) that the software that their own company was > developing should be allow to run on their company’s computers. > > Unbelievable… > > Thomas F. Divine > http://www.pcausa.com > > > -------------------------------------------------- > From: > Sent: Tuesday, March 23, 2010 11:46 AM > To: “Windows System Software Devs Interest List” > Subject: RE:[ntdev] Problem debugging Win7 64bit target > > > Update: I did a fresh clean install of windows 7 on the target. And > > viola, I can debug over either a 1394 or rs232 connection. I hadn’t done > > too much to the machine before trying kernel debugging – the only thing > I > > > can think of is possibly the antivirus software I had installed (symantec > > endpoint) was to blame. > > > > — > > NTDEV is sponsored by OSR > > > > For our schedule of WDF, WDM, debugging and other seminars visit: > > http://www.osr.com/seminars > > > > To unsubscribe, visit the List Server section of OSR Online at > > http://www.osronline.com/page.cfm?name=ListServer > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer > > > Information from ESET Smart Security, version of virus signature > database 4968 (20100323) > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > Information from ESET Smart Security, version of virus signature > database 4968 (20100323) > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer >
Well, I installed Symantec onto my new clean Win7 install, and kd is still functional. So… I have no idea what caused the problem. Oh, well, at least it is working now.