2

I need to debug a running program running on windows. It some times crashes with "memory access violation".

With windbg (usage of IDE not possible) I attached to running process (it is a requirement the program shall not stop)

The command line is

windbg -g -p <pid>

The problem is that I now catch all first chance exceptions but I am only interested in any second chance exception (do not care which type of exception).

How can I setup windbg to catch any second chance exception?

ToBe
  • 921
  • 1
  • 9
  • 23
  • Have a look in Debug->Event Filters and mark the exceptions as `Disabled` - the will make the debugger to break only on second chance. The dialog is a bit cryptic but with some help from documentation it is possible to set it up correctly. – Alexander Balabin Jul 15 '15 at 16:34
  • Unfortunatly this dialog is disabled when "Debuggee is running" and also disabled when I am not attached. It is only available when process is breaked. I am not allowed to break process. – ToBe Jul 16 '15 at 12:52

1 Answers1

6

WinDbg will catch second chance exceptions by default, so you just need to turn off the first chance exceptions. Doing this for a single type of exception is simple:

0:000> sxd av
0:000> *** Check the setting
0:000> .shell -ci "sx" find "av"

See set all exceptions to set all exception types to second-chance only.

Since it does not seem to be an option to perform those commands at debug time, you can also try to configure a Workspace that has exception handling disabled and then reuse the workspace. For understanding the concept of Workspaces, the MSDN article Uncovering how Workspaces work was really helpful. It is a set of experiments that you should do yourself once.

With that background knowledge, attach to any process

0:000> .foreach(exc {sx}) {.catch{sxd ${exc}}}
0:000> *** perhaps some other useful workspace relevant commands here
0:000> ***    e.g. .symfix seems useful
0:000> *** File / Save Workspace As ...
0:000> *** Enter a name, e.g. myworkspace
0:000> q

Restart WinDbg with the -W myworkspace command line switch. Attach to any process. Check if your setting have been applied (e.g. sx, .sympath). If everything is fine, you can start debugging.

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • 1
    Thanks for your answer. This idea is working. However, I have to break/stop my running process from debugger to enter this command. Pausing the process is not allowed in my use case. I am searching for a solution to setup debugger before attaching to process. – ToBe Jul 16 '15 at 12:48
  • I have tried this already, this command line option will be executed after first break/catch. – ToBe Jul 16 '15 at 14:31
  • @ToBe: I don't understand yet what's so critical about breaking in. Use `-c "sxd av;g"` should have little impact. Otherwise, a configured workspace might do. Load the workspace using `-W `. I'll try to extend the answer later. – Thomas Weller Jul 16 '15 at 17:19
  • 1
    @ThomasWeller: The program sends periodically a signal that is guarded by watchdog (hardware). If the program stops because of break of debugger it will in consequence shut down the environment. The environment is needed to reproduce error. But using a pre-setup via workspace is a promising idea. – ToBe Jul 17 '15 at 11:29
  • The workspace approach seems to work. I added some details. – Thomas Weller Jul 19 '15 at 20:00