I don't know where i make a mistake. I try to connect mi host pc (Windows 7) to target pc (virtual machine with Windows 7) in order to start with remote kernel debugging.
Vmware (virtual machine) serial port settings:
Windgb kernel debugging:
Boot virtual machine settings:
If I turn on or turn off virtual machine, nothing happens..
Does anyone know what I'm doing wrong? By the way, is it possible to view content of variables in a driver using LiveKd?
I changed debug port to 2 and host machine can connect to target machine, but windbg get error message "Assertion failed: Missing StreamContext Support ..." and VM hangs at the "Starting Windows" and nothing more happens..
Those settings look correct to me. Occasionally when I see the same behavior I just tell WinDbg to "Break" and that appears to finish the connection.
I've been struggling with much the same thing. It's been a while since I've spent much time kernel debugging with Windbg. I run Linux for pretty much everything, so this time I tried using two KVM/QEMU VM's managed by Libvirt. Lots of different complexity there, since the version of Libvirt I'm using doesn't provide easy "ui" methods of connecting serial ports between VMs (Libvirt hint: the XML setup for the serial ports, one system's Serial port source type must be set to "bind" and one system set to "connect", even for serial type "unix")
Finally, I was able to use Putty on both VM's and chat back and forth, confirming the COM ports I've chosen are indeed connected.
... and still Windbg on my debug host continued to say "Waiting to connect..."
Just confirming #jcopenha's answer, sending Break did just work for me (I don't have Break on my laptop kbd, so I used the Debug Menu to choose "Break").
The Target system is frozen (yes, after the target was fully booted, which was another question I couldn't remember the answer to), and !process gives me interesting info from the target system. I would Up-Vote their answer, but I am new to StackOverflow and don't have the reputation yet.
Thank you!
Related
I have a problem trying to change to run mode when the target device is the PLC (in local mode the problem disappears). It gives me the error: AdsError: 4115 (0x1013, RTIME: system clock setup fails). I have tried to execute win8settick.bat as administrator and rebooting so many times. I have checked the Hyper-V config and BIOS visualizator too. There is nothing that works for me. Any idea? Thank you
Ive only had this problem when trying to start it locally.
But one problem might be that the PLC time is way off. One suggestion to start troubleshooting would be to check the actual time on the PLC.
You can do this by either remotely accessing it via RDP or by plugging in a monitor and keyboard.
Sounds for me like a incompatibitility between TwinCAT-Realtime-System and the hardware. More exatly the CPU. What type of hardware do you use on your target system? Is it Beckhoff-Hardware or Third-Party. If third-party, which CPU?
Another topic could be the TC-Version related with the Target OS. Can you provide more information about this.
I tried to use KGDB on Ubuntu 14.04.2 - 3.16 kernel.
Target is running with 3.16 kernel on Ubuntu 14.04.2.
Host is running with 3.16 kernel on Ububtu 14.04.2.
Target is waiting for remote gdb connection.
Started my Host mechine and try to connect target..
$ gdb ./vmlinux
kernel image file of target machine.
$ gdb> target remote /dev/ttyS0
“unrecognized item timeout in qsupported response”.
Not able to proceed further. Can any one pass some lite on this?
The “unrecognized item timeout in qsupported response” error message most typically occurs when the serial connection between the debug station (GDB host) and target (SUT) is not running reliably in my experience. The usual solution is to do two things. FIRST, check the serial connection manually using a program such as minicom, setserial, and sty. (Check your baud rate match, and that characters appear to transfer between the two systems OK manually). Unfortunately, in my experience, the even with the correct RTS/CTS hardware flow control dongles interspersed, the KDBG agent on the target doesn't handle flow control well. So the manual test will appear to work (no real flow control with a manual test, but it does prove you have correct baud rate control on both ends and complete control). SECOND, and the typically required best solution in my experience is to lower the baud rate down to 9600. (Everyone starts at MAX, or 57600, or 34K, or 19200), but drop it to down to 9600. The data sent/received by the kernel debugger is small, and even the serial console doesn't generate a lot of data in debug situations. By locking the baud rate down to 9600, you wake sure the SUT serial kgdboc keeps up on the target, and the problem you are seeing usually goes away. If you find the speed too slow, once you have it running properly at 9600, then you can increase the speed back up one step at a time (on both ends) and find the maximum serial rate for your setup that works properly.
I am new to driver stuff. I have tried to debug the kernel driver using serial COM port without success. Could someone show me proper direction how to fix the problem?
I am seeing the following messages on kd console.
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127
At this time, I pressed Ctl^D and kd console and I am seeing
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
EDIT: The problem is fixed with WinDbg. I changed the baud rate to 115200 and inserted break (Ctr ^ Break) before Target system completely boots up. I am able to debug the code now. If I insert break after the target system completely boots up then I am unable to debug. I don't know exact reason for it but Happy with current situation.
Here are the things I have done
1) Prepared Target system for debug mode by editing the boot.ini file. Added “/debugport=com1 /baudrate=57600” to boot.ini
2) On Host system, started kd.exe and seeing the following output
C:\Program Files\Debugging Tools for Windows>kd.exe -k com:port=1,baud=57600
Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \\.\com1
Waiting to reconnect...
3) Rebooted Target system, system boots slowly than normal boot and I am seeing some messages <<below>> on Host system console
4) At this time, If I press Ctl-C on KD console then Target system freezes (hangs) and proceeds if I enter "g" at kd prompt. This means that Target system is going to debug mode
5) However After some time I am seeing the following message on the host machine console
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127
After the above message there are no messages appearing on kd console.
I searched internet for "ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127" but didn't get proper reason for it.
I pressed Ctl^D and kd console and I am seeing
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
I have tried above steps with following options ..but no luck
I disabled firewall & antivirus software on both Host and Target systems.
I unplugged and re-plugged serial cable connection between each trail
I have logged-in with Domain account local account with Admin rights
Can someone show some light on how to proceed? Both systems are running on XP 32bit SP3 OS.
Thanks
King
Are you sure you have a good serial connection?
The cable must be a null modem cable - you should verify this using a terminal program (without kernel debugging enabled on the target). Run the program (HyperTerminal or whatever) on both the target and the host machines (remember, like I said before kernel debugging over that port must not be enabled on the target or the port can't be opened).
You can find some links to free terminal programs (I don't think Microsoft provides HyperTerminal anymore since Vista) here: http://www.lvr.com/serport.htm#software
Type some characters on one machine, and make sure they show up on the other side. Do the same on the other machine.
If you can't do this, then there's no serial connection and you'll have to get a null modem cable or adapter. There's no point in trying to get KD to work over that connection until you can do this.
Also, remember that the COM port used by kernel debugging on the target must be a standard 8250 family UART (usually a 16550 or better nowadays, and usually baked into the motherboard chipset). It can't be a USB serial port connector (although that kind will work fine on the host side, since on the host kd.exe is a regular Win32 program).
Edit:
If it's not a serial connection problem, the problem might be that your target doesn't support configuration using boot.ini. Since Vista, boot parameters have been specified using the "Boot Configuration Database" (BCD) which is manipulated with a program like bcdedit.exe. Unfortunately, configuring a system using BCDedit is much more complicated than just editing a simple text file like boot.ini.
You should read the debugger helpfile section "Configuring Software on the Target Computer"; in particular the "Using Boot Parameters" part. there are details there on how bcdedit can be used to enable debugging on Vista and later systems.
The other thing you can test to see if debugging is working on the target is to invoke kd -kl on the target - if it tells you debugging isn't enabled, you haven't set up boot.ini correctly.
Does anyone know ways of partially or fully automating driver test installation?
I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.
After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?
Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.
It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.
But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:
... This project brings the simplicity and
convenience of Windows application
development to the driver development
world. No more manual creation of
build scripts, copying of driver
files, installing drivers from INFs,
switching between WinDbg and the
source editor or waiting for seconds
after each step due to the extra-slow
virtual COM port. Just create a driver
project using a convenient Driver
Wizard, select a virtual machine, and
enjoy debugging your driver directly
from Visual Studio. Want to test a
change? Just normally press Shift-F5,
modify your driver, rebuild it and
launch again. VisualDDK will unload
the old driver, install the new one
and load it automatically and quickly.
Bored with WinDbg loading symbol files
for minutes and looking up symbols for
seconds? Just let VisualDDK optimize
this for you using its own DIA-based
symbol engine. Using C++/STLPort in
your drivers? VisualDDK will natively
visualize all STL containers and
strings, as good as Visual Studio does
for user-mode applications. ...
You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).
Don't forget to check your driver with DriverVerifier!
Example of my own script :)
sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter
Follow the advice I gave here. Basically, test as little as possible with the real system.
In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).
You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).
I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.
It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.
I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.
One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.
Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.
I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.
It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.
What is your favorite technique for launching a windbg user-mode remote debugging session?
Why is do you prefer this technique over other techniques? (pros/cons)
There are at least four different ways to do user-mode remote debug using windbg, as documented in the "Remote Debugging" section of the debugging tools for windows help file.
run app on target then attach to it from the host windbg
have the host windbg use remote.exe to launch the app on the target
have the "smart client" host windbg launch the app on the target via a process server that is running on the target
run a windbg instance on the target machine using the option "-server" to automatically start a server, then connect to the server from a 2nd machine.
Option 1 is my favourite because it is the simplest. I get to launch the app in the normal way without worry about getting WinDbg to set the right working directory, pass any command line arguments, etc.
Fortunately I've not run into any cases where this hasn't worked!
There is no "the best" solution. Each of the possibilities has advantages and disadvantages and it's good to understand all of them. It depends on several factors like:
where are the symbols located
which PC has access to the Internet to download the OS symbols
what amount of data may you copy to the server (clients often accept better if it's just a single Exe)
what's the bandwidth between client and server
do you need other commands that just CDB/WinDbg, e.g. access to CMD, then consider remote.exe
who's available on the server side, a debugging expert whom you can easily tell a lot of cryptic commands or a normal user who barely knows how to start a command prompt
are both sides in a private network, so you need a "man in the middle" server to be able to access each other (or port forwarding as an alternative, which IT guys don't want and it may take days to get it set up)
From those 4 options, don't forget that clients often want to see exactly what you do, so they require an RDP session, Teamviewer or similar. That's something they understand.
I tend to use option 4 (-server) because it is the only one that doesn't "pop" when you break into the kernel debugger long enough for the TCP connection to timeout. But this is more complex and not fully satisfying. So I'm looking for "best practices".