I have an extension written to do very simplistic basic stuff, but what my end goal is this:
Given an address to a context do the following:
Doing this by hand takes a very long time and lots of !do
Anyone have any pointers and or places that know how to take the address and get information abotu the object at the address and parse its members and assign them to variables to dig deeper into the object?
Are you asking (a) how to write an extension; or (b) how to parse network
structures?
Mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@integra.net
Sent: Thursday, September 23, 2010 4:42 PM
To: Kernel Debugging Interest List
Subject: [windbg] Trying to Write an extension to dig into
HTTPContext/Request/Headers
I have an extension written to do very simplistic basic stuff, but what my
end goal is this:
Given an address to a context do the following:
Doing this by hand takes a very long time and lots of !do
Anyone have any pointers and or places that know how to take the address and
get information abotu the object at the address and parse its members and
assign them to variables to dig deeper into the object?
WINDBG is sponsored by OSR
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
Creating an extension. I have one thats working right now but may be the long of getting to the data structures. Basically I created structures of ULONG/64’s for the CONTEXT, request, header, array list and basically do a READMEMORY into that structure. But now I am curious if there is a faster way for recognizing the structures without having to write one for every object we want to dump the contents for?
Seems like this was a bit long winded and the context structure should be able to be pulled out similar to how psscor2 extensions do. Unless this is exactly what they are doing also.
example of what i did:
typedef struct _HTTPCONTEXT64 {
ULONG64 MethodTable;
ULONG64 AsyncAppHandler;
ULONG64 AppInstance;
ULONG64 Handler;
ULONG64 Request;
ULONG64 Response;
//TODO Add Additional Objects if we need them
} HTTPCONTEXT64, *PTRHTTPCONTEXT64;
static ULONG64 httpcontextaddress;
static ULONG64 address = 0;
char stringaddress[20] = {0};
ULONG _bytes;
HTTPCONTEXT64 context;
HTTPREQUEST64 request;
HTTPHEADER64 header;
ARRAYLIST64 list;
httpcontextaddress = GetExpression(args);
if(httpcontextaddress != 0)
{
address = httpcontextaddress;
}
dprintf (“Attempting to dump HTTPContext at 0x%016I64x\n\n”, address);
//GetSymbol(_address, symbol, length);
ReadMemory(address, &context, sizeof(HTTPCONTEXT64), &_bytes);
Oh and the reason for having to do all this is I am troubleshooting an IIS application in 64 bit that is eventually getting to a point the app pool quits responding and when digging there are lots of long running requests and I am dumping all those memory structures to simulate the problem.
You can use symbolic debugging information (when available) to handle this
task; however, it’s more involved and while I would imagine that you can do
this using the type of kd extension model that you are using (Wdbgext), I
don’t know how, as I don’t use that type - it’s old.
My guess would be that Ioctl(IG_DUMP_SYMBOL_INFO) would be one way to go
about getting type information:
http://msdn.microsoft.com/en-us/library/ff550906(VS.85).aspx
If you’re not too far along in the process, I would consider taking a look
at the DbgEng and EngExtCpp extension models. I prefer the latter and in
particular, take a look at the ExtRemoteTyped class (for example, as in the
‘extcpp’ sample (/Debuggers/sdk/samples/extcpp):
From that sample (for example):
ExtRemoteTyped Node = LdrList.GetTypedNode();
Out(“Loader list entry at %p\n”, LdrList.GetNodeOffset());
Out(" full path ‘%msu’\n",
LdrList.GetNodeOffset() + Node.GetFieldOffset(“FullDllName”));
Node.OutFullValue();
Out(“\n”);
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@integra.net
Sent: Tuesday, September 28, 2010 10:30 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Trying to Write an extension to dig into
HTTPContext/Request/Headers
Creating an extension. I have one thats working right now but may be the
long of getting to the data structures. Basically I created structures of
ULONG/64’s for the CONTEXT, request, header, array list and basically do a
READMEMORY into that structure. But now I am curious if there is a faster
way for recognizing the structures without having to write one for every
object we want to dump the contents for?
Seems like this was a bit long winded and the context structure should be
able to be pulled out similar to how psscor2 extensions do. Unless this is
exactly what they are doing also.
example of what i did:
typedef struct _HTTPCONTEXT64 {
ULONG64 MethodTable;
ULONG64 AsyncAppHandler;
ULONG64 AppInstance;
ULONG64 Handler;
ULONG64 Request;
ULONG64 Response;
//TODO Add Additional Objects if we need them
} HTTPCONTEXT64, *PTRHTTPCONTEXT64;
static ULONG64 httpcontextaddress;
static ULONG64 address = 0;
char stringaddress[20] = {0};
ULONG _bytes;
HTTPCONTEXT64 context;
HTTPREQUEST64 request;
HTTPHEADER64 header;
ARRAYLIST64 list;
httpcontextaddress = GetExpression(args);
if(httpcontextaddress != 0)
{
address = httpcontextaddress;
}
dprintf (“Attempting to dump HTTPContext at 0x%016I64x\n\n”,
address);
//GetSymbol(_address, symbol, length);
ReadMemory(address, &context, sizeof(HTTPCONTEXT64), &_bytes);
—
WINDBG is sponsored by OSR
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
This works for me, I will take a look at this. I would rather be doing it the new way instead of the old. I also order Advanced .Net Debugging book hoping it will help out in this process. I will look into those samples and see if I can make progress. If you dont mind me asking, what is the differences in the old way and the new way in summary?
DbgEng is basically the client side of the debugger. It exposes a lot of
functionality.
EngExtCpp is a C++ wrapper around parts of DbgEng. I find it very
convenient, and you can always drop down to DbgEng at anypoint.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@integra.net
Sent: Tuesday, September 28, 2010 11:47 AM
To: Kernel Debugging Interest List
Subject: RE:[windbg] Trying to Write an extension to dig into
HTTPContext/Request/Headers
This works for me, I will take a look at this. I would rather be doing it
the new way instead of the old. I also order Advanced .Net Debugging book
hoping it will help out in this process. I will look into those samples and
see if I can make progress. If you dont mind me asking, what is the
differences in the old way and the new way in summary?
WINDBG is sponsored by OSR
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
You can also read this article for a quick start on the DbgEng interface:
http://www.osronline.com/article.cfm?article=559
It also has a simple example of working with typed information from DbgEng.
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@windbg…
> This works for me, I will take a look at this. I would rather be doing it
> the new way instead of the old. I also order Advanced .Net Debugging book
> hoping it will help out in this process. I will look into those samples
> and see if I can make progress. If you dont mind me asking, what is the
> differences in the old way and the new way in summary?
>