setting more than 32 bp

Is there a way to set more than 32 bps in windbg?

thx
-pro

None that I’m aware of. AFAIK this is a hard coded limit in the O/S itself.

Of course, you could write your own code to do this if you really, *really*
needed it for a particular purpose. It could potentially even be entirely on
the host side, sort of like what I described here:

https://www.osronline.com/article.cfm?id=611

The byte code would of course be different (0xCC), but the idea would be the
same.

-scott
OSR

“Sinha Prokash” wrote in message
news:xxxxx@windbg…
Is there a way to set more than 32 bps in windbg?

thx
-pro

Thanks Scott…

I will look at the article.

-pro

From: xxxxx@osr.com
Subject: Re:[windbg] setting more than 32 bp
Date: Tue, 10 Sep 2013 16:27:17 -0400
To: xxxxx@lists.osr.com

None that I’m aware of. AFAIK this is a hard coded limit in the O/S itself.

Of course, you could write your own code to do this if you really, *really*
needed it for a particular purpose. It could potentially even be entirely on
the host side, sort of like what I described here:

https://www.osronline.com/article.cfm?id=611

The byte code would of course be different (0xCC), but the idea would be the
same.

-scott
OSR

“Sinha Prokash” wrote in message
> news:xxxxx@windbg…
> Is there a way to set more than 32 bps in windbg?
>
> thx
> -pro
>
>
> —
> WINDBG is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> 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

> None that I’m aware of. AFAIK this is a hard coded limit in the O/S itself.

In the OS? Why? Assuming you are talking about CODE breakpoints, OS does not care how many INT3’s you place in the code?

When you set a breakpoint in Windbg the work of actually setting the breakpoint happens on the target, including saving the bytes and then overwriting them with the int 3. The breakpoint locations and previous bytes are stored in a fixed size array on the target, hence the limit.

It would of course be possible to do this from the host by simply reading/writing memory (hence the article). However, then you have the problem of how to gracefully recover in the case of the debugger aborting. Ideally you wouldn’t need to reboot the target machine in this case, which means a target side assist.

-scott
OSR