MS_VC_EXCEPTION with a dwType 0f 0x1001, and a subcode of 0x1004. Meaning ?

[R.Wieser]

Hello All,

I'm catching debugging events, and saw one I cannot really find anything
about. The Debug-event carries a type-code of MS_VC_EXCEPTION. But than I
get stuck.

Following the argument count of 0x00000006 I get this:
00001001 00001004 0012936B 00000000 00000000 00000000

All google turned up was the setThreadName function, but it simply does not
match. It has just 4 arguments instead of 6, and the dwType should than
have been 0x00001000, with the second argument a (user-space) pointer to a
string.

In short: does anyone here know where to find a list of MS_VC_EXCEPTION
sub-codes and their structures ?

Regards,
Rudy Wieser

[Geoff]

On Wed, 17 Apr 2013 13:48:23 +0200, "R.Wieser" <add...@not.available>
wrote:

It looks like you may be looking at an exception record structure. I
don't know anything more than that.

typedef struct _EXCEPTION_RECORD {
DWORD ExceptionCode;
DWORD ExceptionFlags;
struct _EXCEPTION_RECORD *ExceptionRecord;
PVOID ExceptionAddress;
DWORD NumberParameters;
ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
} EXCEPTION_RECORD, *PEXCEPTION_RECORD;

[R.Wieser]

Hello Geoff,

> It looks like you may be looking at an exception record
> structure.

Yes, I am. :-)

The type-code and argument count I referred to are fields 'ExceptionCode'
and 'NumberParameters' respectivily. The data I showed is directly
following that 'NumberParameters' field, and forms the
'ExceptionInformation[]' array.

Alas, that is how far I got. No info on the contents of that array (but
for the one case I named)

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws
vctum8punkm8n4l3n...@4ax.com...

[Geoff]

Rudy,

I've never dabbled in SEH in my Windows apps so I don't have any
experience to go on. I'd probably start with SetThreadName in my
threads and see how it affects the data you get when the exception
gets thrown.

You might also try analyzing the app by attaching WinDbg to the
process and see if knows more about the exception information struct.

Good luck. :)

On Thu, 18 Apr 2013 09:49:43 +0200, "R.Wieser" <add...@not.available>

[R.Wieser]

Hello Geoff,

> I'd probably start with SetThreadName in my threads and
> see how it affects the data you get when the exception gets
> thrown.

:-) Exactly what I thought. I've got some VC++ source code here, which I
compile with Visual Studio 2008 -s VC++ . I stuck that command in there
somewhere and tried to recompile. Alas, the compiler threw an error on it
("Identifier not found").

> You might also try analyzing the app by attaching WinDbg
> to the process and see if knows more about the exception
> information struct.

I did not think of that (have no experience with attaching debuggers), but
have to try I guess.

... But that will only give me information on that one debug-event.

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

tov3n89ejq6l0l8sj...@4ax.com...

[Geoff]

I grabbed the sample code from MSDN and built this as a console app:

//
// Usage: SetThreadName (-1, "MainThread");
//
#include <windows.h>
#include <cstdio>

const DWORD MS_VC_EXCEPTION = 0x406D1388;

#pragma pack(push,8)
typedef struct tagTHREADNAME_INFO
{
DWORD dwType; // Must be 0x1000.
LPCSTR szName; // Pointer to name (in user addr space).
DWORD dwThreadID; // Thread ID (-1=caller thread).
DWORD dwFlags; // Reserved for future use, must be zero.
} THREADNAME_INFO;
#pragma pack(pop)

void SetThreadName( DWORD dwThreadID, char* threadName)
{
THREADNAME_INFO info;
info.dwType = 0x1000;
info.szName = threadName;
info.dwThreadID = dwThreadID;
info.dwFlags = 0;

__try
{
puts("in try");
RaiseException(11111, 0, sizeof(info)/sizeof(ULONG_PTR),
(ULONG_PTR*)&info );
}
__except(puts("in filter"), EXCEPTION_EXECUTE_HANDLER)
{
puts("Exception was handled...");
DWORD ec = GetExceptionCode();
printf("Exception code: %i in %s: ID %i\n", ec, info.szName,
info.dwThreadID);
}
}

int main ()
{
HANDLE mythread = GetCurrentThread();
DWORD myThreadID = GetThreadId(mythread);
SetThreadName (myThreadID, "MainThread");
}

If I replace 11111 with MS_VC_EXCEPTION the __except block isn't
executed when I run it in the debugger but it is executed when I run
it in a console. If you're getting that exception in your application
I'd have to conclude you've got some interesting debugging ahead. If
you're going to throw your own exceptions then you simply use your own
codes.

Here's a list of exception codes:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679356(v=vs.85).aspx

[R.Wieser]

Hello Geoff,

> I grabbed the sample code from MSDN and built this as a console app:

Thanks for that code, I'm certainly going to try it.

> Here's a list of exception codes:

Yes, I found that list too. I had implemented a number of them when I saw
the a MS_VC_EXEPTION being generated by a program (found the name by
googeling the exception-code). Alas, the list does not mention it, let alone
any of its sub-codes. Thats is how I came here :-)

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

vqb5n8hp439pe4ob6...@4ax.com...

[R.Wieser]

Hello again Geoff,

> I grabbed the sample code from MSDN and built this as a console app:

I had to change your

> HANDLE mythread = GetCurrentThread();
> DWORD myThreadID = GetThreadId(mythread);

code to

DWORD myThreadID = GetCurrentThreadId(mythread);

after which it worked alright (I'm on XP sp3. It does not have
'GetThreadId()' in Kernel32). I got the "11111" as an exception-code, and
after changing it to MS_VC_EXCEPTION I got that one too, exactly as
described in the structure..

> If I replace 11111 with MS_VC_EXCEPTION the __except
> block isn't executed when I run it in the debugger but it is
> executed when I run it in a console.

It might be that the debugger silently captures & handles the exception. It
is after all MS VC specific, and quite undocumented.

> If you're getting that exception in your application I'd have to
> conclude you've got some interesting debugging ahead.

How do you mean ?

By the way: My exception-event capturer isn't written in VC++. Its just
that as the exception is MS VC specific I thought that this would be the
most appropriate newsgroup to ask for its meaning.

> If you're going to throw your own exceptions then you simply
> use your own codes.

No, currently I just want to be able to see whatever events a particular app
throws. I might have used a ready-to-use debugger, but writing your own
tools is more fun (and educational to boot).


Remarkably, I got that other exception (subcode 0x00001001), the one I
mentioned in my first post, too.

So, I know that my code does indeed "capture" those events correctly, but
I'm still stuck in regard to MS_VC_EXCEPTIONs other subcodes. :-\

Regards,
Rudy Wieser


-- Origional message:
Geoff <ge...@invalid.invalid> schreef in berichtnieuws

vqb5n8hp439pe4ob6...@4ax.com...

[R.Wieser]

Hello Geoff,

> > If I replace 11111 with MS_VC_EXCEPTION the __except
> > block isn't executed when I run it in the debugger but it is
> > executed when I run it in a console.

Whoops, my mistake. As far as I can tell that is how it should work.

The MS_VC_EXCEPTION event is handled by the debugger, which (probably)
returns a DBG_CONTINUE status-code (my program does).
Your own "11111" event-code isn't recognised, and therefore the debugger
(probably) returns a DBG_EXCEPTION_NOT_HANDLED. That in turn leads to the
__except code being invoked.

At least, that is what I think what happens ...

Regards,
Rudy Wieser

[Geoff]

On Mon, 22 Apr 2013 23:13:39 +0200, "R.Wieser" <add...@not.available>
wrote:

That makes sense based on the experiments I conducted.