debugbreak continue issue

Hello everyone,


What makes me confused is,

In MSDN document,

http://msdn2.microsoft.com/en-us/library/cc266343.aspx

the sequence to handle int 3 debug exception is,

1. search for attached debugger;
2. search for exception handler;
3. search for kernel debugger;
4. invoke JIT debugger.

If we go to step 4, it means no exception handler. But in the break-continue-ignore dialog, it is mentioned in document that if we select continue, we will go to exception handler, I think it is a conflict... Because if we are in step 4, means step 2 is passed -- which means no exception handler.

Any comments?


thanks in advance,
George

Obviously, if it can't find an attached debugger, it searches steps 3 & 4.

Hi Elysia,


1. If we go to step 4, means step 2 is not satisfied, means no exception handler, right?

2. If we select continue in step 4, means search for exception handler, but it is obviously no exception handler exists (if there were, we will in step 2 other than step 4).

Here is why I am confused. Any comments?

Quote:

---

Originally Posted by Elysia

Obviously, if it can't find an attached debugger, it searches steps 3 & 4.

---

regards,
George

Erm what, huh, no?
In step 4, it searches for a JIT debugger and launches it if you will. It's the debug dialog.
The "assert dialog" is not step 4. It's step 0. When you click continue, it invokes int 3, thus starting the chain.

Thanks Elysia,


I have tried in command line, when executing DebugBreak, there will be the following events happen,

(running from command line)

1. select whether to send debug information to Microsoft
2. JIT debugger dialog will be ok and let us select which debugger to use;
3. If we select Visual Studio, then the break-continue-ignore dialog will be displayed.

Do you meet with the same sequences in your environment (I have attached the code below)? If yes, as you mentioned, your step "assert dialog" is my step 3 (assert dialog you mean the break-continue-ignore dialog)? And your step 4 is my step 2? So, in your environment, step 3 happens before step 2?

--------------------
In step 4, it searches for a JIT debugger and launches it if you will. It's the debug dialog.
The "assert dialog" is not step 4. It's step 0. When you click continue, it invokes int 3, thus starting the chain.
--------------------

Code:

---

#include "Windows.h"

int main()
{
        int a;
        int b;
        int c;
/*
        __try
    {
*/       
                a = 100;
                b = 200;
                c = 300;

                DebugBreak();
                a = 400;
/*       
    }
    __except(GetExceptionCode() == EXCEPTION_BREAKPOINT ?
            EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
    {
        // No debugger is attached, so return FALSE
        // and continue.
        return FALSE;
    }
*/       
    return TRUE;
}

---

Quote:

---

Originally Posted by Elysia

Erm what, huh, no?
In step 4, it searches for a JIT debugger and launches it if you will. It's the debug dialog.
The "assert dialog" is not step 4. It's step 0. When you click continue, it invokes int 3, thus starting the chain.

---

regards,
George

If it's the same code as in the other thread (the __except handler), then I will outline what happens:

Scenario: I run the app with no debugging.
What happens: The code executes, DebugBreak is involved.
Step 1 is executed, but no attached debugger is found.
Step 2 is executed, an __except handler is found so execution jumps to this point which terminates the program.

Scenario: I run the app with debugging.
What happens: The code executes, DebugBreak is involved.
Step 1 is executed, and an attached debugger is found, so the debugger breaks showing a break interupt was signaled.

Scenario: I run the app with no debugging and remove the __except handler.
Step 1 is executed, but no attached debugger is found.
Step 2 is executed, but no __except handler is found.
Step 3 is executed, but no kernel debugger is found.
Step 4 is executed and a JIT debugger is found. Visual Studio JIT-debugger window select appears. I select a new instance of Visual Studio.
Visual Studio opens and breaks on the DebugBreak line (debug interrupt).
NO assert, NO dialog saying retry/cancel/ignore.
It's a debug interrupt, nothing more.

Thanks Elysia,

Quote:

---

Originally Posted by Elysia

Scenario: I run the app with no debugging and remove the __except handler.
Step 1 is executed, but no attached debugger is found.
Step 2 is executed, but no __except handler is found.
Step 3 is executed, but no kernel debugger is found.
Step 4 is executed and a JIT debugger is found. Visual Studio JIT-debugger window select appears. I select a new instance of Visual Studio.
Visual Studio opens and breaks on the DebugBreak line (debug interrupt).
NO assert, NO dialog saying retry/cancel/ignore.
It's a debug interrupt, nothing more.

---

I mean the above scenario. I think the problem is, you did not close the Visual Studio when run the application from command line, right? Please close Visual Studio and run from command line, I think you can see the dialog about break/continue/ignore.


regards,
George

Quote:

---

Originally Posted by George2

I mean the above scenario. I think the problem is, you did not close the Visual Studio when run the application from command line, right? Please close Visual Studio and run from command line, I think you can see the dialog about break/continue/ignore.

---

No! Applications are not meant to be run from the command line (I hate the notion that someone should do that) and having Visual Studio open makes no different whatsoever.
I run the programs without debugging, as you see. That means I get the typical JIT-dialog. So I select a new instance, which opens a new instance of Visual Studio and does not use an existing one.
And no dialog pops up, because this is not an assert. This is a break interrupt where the debugger attaches to the program and halts executions at the debug interrupt.
Usually it displays a dialog such as debug or breakpoint or something like that. I can't remember exactly what.
For example, if you open a debugger when a program crashes, you can typically see an error such as "access violation at address." No retry/abort/ignore buttons.

Hi Elysia,


1.

Quote:

---

Originally Posted by Elysia

No! Applications are not meant to be run from the command line (I hate the notion that someone should do that) and having Visual Studio open makes no different whatsoever.

---

As far as I know, there are two ways to run an application, from Visual Studio F5 and from command line Window to type the name of the application. Seems you have the 3rd way, how do you run? :-)

2.

Quote:

---

Originally Posted by Elysia

For example, if you open a debugger when a program crashes, you can typically see an error such as "access violation at address." No retry/abort/ignore buttons.

---

I have attached the dialog, you do not meet with this dialog?


regards,
George

Quote:

---

Originally Posted by George2

As far as I know, there are two ways to run an application, from Visual Studio F5 and from command line Window to type the name of the application. Seems you have the 3rd way, how do you run? :-)

---

Ctrl+F5 (run without debug)

Quote:

---

I have attached the dialog, you do not meet with this dialog?

---

But that's not an assert dialog, but a break dialog and the ignore is greyed out. But yes, you got me there... that's the dialog you should get.
But you see, just clicking continue or ignore won't go searching for exception handlers here. It's not that kind of dialog.

Thanks Elysia,


I want to prove that the continue button is useless. Here is my analysis.

The following events happen in the following sequences,

1. DebugBreak triggers int 3 interrupt;
2. search for attached debugger, if has, go to end step 7;
3. search for exception handler, if has, go to end step 7 and continue
execution in exception handler;
4. search for kernel debugger, if has, go to end step 7;
5. invoke JIT debugger to allow us to select debugger;
6. If we select Visual Studio, a dialog with Break-Continue-Ignore is
jumped, and continue button is used to allow us to jump to exception handler
for int 3 (debug break);
7. end.

My point is, in step 6, continue button is useless since if we are in step
6, it means step 3 is not satisfied, means no exception handler. So, when we
click continue button, there can not be any exception handlers.

Any comments? Have I made myself understood?

BTW: when click F1 on the Break-Continue-Ignore dialog, you will find what means continue.

Quote:

---

Originally Posted by Elysia

Ctrl+F5 (run without debug)


But that's not an assert dialog, but a break dialog and the ignore is greyed out. But yes, you got me there... that's the dialog you should get.
But you see, just clicking continue or ignore won't go searching for exception handlers here. It's not that kind of dialog.

---

regards,
George

Here's what happens:
I use the following code:

Code:

---

        int a;
        int b;
        int c;

        __try
    {
                a = 100;
                b = 200;
                c = 300;

                DebugBreak();
                a = 400;
    }
    __except(GetExceptionCode() == EXCEPTION_BREAKPOINT ?
            EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
    {
        // No debugger is attached, so return FALSE
        // and continue.
                cout << "ERROR!\n";
    }

---

And run with F5 (debugger attached). The dialog pops up when DebugBreak is executed. I click continue. It jumps right past the __except block, as if it wasn't there.
And if I run this code with a debugger, it will catch the exception, so there will be no JIT dialog.
If you comment out the __except handler, then there's no handler to jump to, should you click continue.

Hi Elysia,


I have re-tried in my environment, and I have the same result and totally agree with you. I think you can see why I am confused. I quoted your comments below, which is my confusion point.

In this situation as you mentioned below, I think there is no exception handler (if exception handler exists, you will not goes to this step to let you select debugger), right? So, the continue button is useless and click it will simply terminates the program.

Agree? I do not know why Visual Studio has such a button left. It is useless in this situation.

I am not sure whether in other scenarios the continue button is helpful.

Quote:

---

Originally Posted by Elysia

If you comment out the __except handler, then there's no handler to jump to, should you click continue.

---

regards,
George