Thank You Jen,
if all you need is to check ntdll symbols,
obviously not 
i was thinking about integrating some of windbgâs
functionalities with ollydbg
especially dt outputs etc as an ollydbg plugin any pointers to this
effect would be
great
opening as dumpfile seems to use OutputBuffer() whose string length
doesnât seem to configurable
ollydbg has problems outputting sting len > 0x100 in one go i used
strtok with \n as seperator as a temporary measure and bypassed
but it is bound to break
yes i came to same conclusion that i cant initialize it externally
so did
if( ( status = g_Client->GetRunningProcessSystemIds(
status = g_Client->GetRunningProcessDescription(
if( ( g_Client->AttachProcess (
0,
Pids[0x23],
DEBUG_ATTACH_NONINVASIVE
) ) != S_OK ) {
and then
g_Control->WaitForEvent(
0,
INFINITE
);
}
if ( ( status = g_Symbols->GetSymbolTypeId(
ântdll!_EPROCESSâ,
&TypeId,
&ModuleInfo
) ) != S_OK ) {
printf(âg_Symbols GetSymbolTypeId Failed With %x\nâ ,status ) ;
return 0;
} else {
printf(
âg_Symbols GetSymbolTypeId Succeded returned %x\nâ
âTypeId %x\nâ
âModuleInfo %x\nâ,
status,
TypeId,
ModuleInfo
);
this seems to fetch the result
F:\windbg\612windbg>DumpSym.exe
Debug Create Succeded returned 0
Query Interface IDebugControl Succeded returned 0
Query Interface IDebugSymbols Succeded returned 0
SetOutPutCallBacks Succeded returned 0
g_Client->GetRunningProcessSystemIds Succeded returned 0 no of processids 26
Processid = 0
process Name is System Process
Processid = 4
process Name is System
Processid = 33c
process Name is smss.exe
Processid = 390
process Name is csrss.exe
Processid = 3a8
process Name is winlogon.exe
Processid = 3d4
process Name is services.exe
Processid = 3e0
process Name is lsass.exe
Processid = 478
process Name is svchost.exe
Processid = a50
process Name is DumpSym.exe
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
attach success
*** wait with pending attach
Symbol search path is: SRV*F:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
WARNING: Process 2832 is not attached as a debuggee
The process can be examined but debug events will not be received
âŚ
(b10.f84): Wake debugger - code 80000007 (first chance)
g_Symbols GetSymbolTypeId Succeded returned 0
TypeId 3
MOduleInfo 7c900000
0 (+000) Pcb
1 (+06c) ProcessLock
2 (+070) CreateTime
3 (+078) ExitTime
4 (+080) RundownProtect
5 (+084) UniqueProcessId
On 4/23/12, Jen-Lung Chiu wrote:
> You need to have some debugged target that dbgeng/dbghelp could operate on.
> The global target would only be created through IDebugClient interface
> function calls (AttachKernel(), AttachProcess(), CreateProcessAndAttach(),
> OpenDumpFile(), âŚ).
>
> If all you need is to check ntdll symbols, you could call OpenDumpFile()
> with ântdll.dllâ as the dump file name parameter. Once you have the symbol
> path correctly set, this would work.
>
> Thanks,
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
> Sent: Monday, April 23, 2012 12:34 AM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] IDebugSymbols Methods Failing With E_UNEXPECTED
> (0x8000ffff)
>
> Thanks For Replying back Jen
>
> From my Earlier Experiments i learnt any app i compile must be run from a
> folder where the latest dbgeng,dbghelp, and extension dlls reside
>
> so i normally run the compiled exe from windbg folder and last tiem i
> checked as noted in my social.msdn link posts the dlls were loading still i
> would go back and confirm if symsrv is loading or not
>
> but can you clarify something more
> i was reading and gazing through dbgeng a bit more and it seems for anything
> symbol related this global g_Target need to be initialized at present this
> global seems to be initialised only from a few places and it is not obvious
> if i can initialize it externally
>
> something like
> g_Target = * ( g_TARGET * )getvalue(someblah)
>
> or simply
>
> __asm {
> mov [g_Target] , result_from_get_g_Target_equivalent()
> }
>
> as i can see the path of failure in my case is like this
>
> dbgeng!DebugClient::GetSymbolTypeIdWide+0x92:
> 02122142 833d4850360200 cmp dword ptr [dbgeng!g_Target (02365048)],0
> ds:002
> 3:02365048=00000000
> 0:000> th
> dbgeng!DebugClient::GetSymbolTypeIdWide+0x99:
> 02122149 7435 je
> dbgeng!DebugClient::GetSymbolTypeIdWide+0xd0 (0
> 2122180) [br=1]
> 0:000> t
> dbgeng!DebugClient::GetSymbolTypeIdWide+0xd0:
> 02122180 c785b8feffffffff0080 mov dword ptr [ebp-148h],8000FFFFh
> ss:0023:0007fa9
> 4=00000000
> 0:000>
>
>
> initialisations for this global happen here
>
>
> 0:000> # "movg_Target ," 02000000 L?(0239b000-02000000)
> dbgeng!StackSaveLayers::~StackSaveLayers+0xe:
> 020ebafe 890d48503602 mov dword ptr [dbgeng!g_Target (02365048)],ecx
> dbgeng!DebugClient::AttachKernelWide+0x97:
> 020fa897 891548503602 mov dword ptr [dbgeng!g_Target (02365048)],edx
> dbgeng!DebugClient::AttachProcess+0xcb:
> 020fb89b 890d48503602 mov dword ptr [dbgeng!g_Target (02365048)],ecx
> dbgeng!DebugClient::CreateProcess2Wide+0x17c:
> 020fbedc 890d48503602 mov dword ptr [dbgeng!g_Target (02365048)],ecx
> dbgeng!DebugClient::CreateProcessAndAttach2Wide+0x152:
> 020fc462 a348503602 mov dword ptr [dbgeng!g_Target (02365048)],eax
> dbgeng!DebugClient::OpenDumpFileWithPrivateDumpHeader+0x96:
> 020fcac6 a348503602 mov dword ptr [dbgeng!g_Target (02365048)],eax
> dbgeng!FindEventProcessThread+0xd6:
> 02177a46 891548503602 mov dword ptr [dbgeng!g_Target (02365048)],edx
> dbgeng!LiveUserTargetInfo::WaitForEvent+0x49a:
> 0217bf0a a348503602 mov dword ptr [dbgeng!g_Target (02365048)],eax
> dbgeng!SetLayersFromTarget+0x8:
> 02271b88 a348503602 mov dword ptr [dbgeng!g_Target (02365048)],eax
> dbgeng!SetLayersFromProcess+0xd:
> 02271c0d c7054850360200000000 mov dword ptr [dbgeng!g_Target (02365048)],0
> dbgeng!SetLayersFromProcess+0x3c:
> 02271c3c 891548503602 mov dword ptr [dbgeng!g_Target (02365048)],edx
> dbgeng!SetLayersFromThread+0xd:
> 02271c7d c7054850360200000000 mov dword ptr [dbgeng!g_Target (02365048)],0
> dbgeng!SetLayersFromThread+0x49:
> 02271cb9 890d48503602 mov dword ptr [dbgeng!g_Target (02365048)],ecx
> dbgeng!TargetInfo::~TargetInfo+0x70:
> 022741d0 c7054850360200000000 mov dword ptr [dbgeng!g_Target (02365048)],0
> ^ Memory access
> error i n '# "movg_Target ,'
> 0:000>
>
>
>
>
>
>
> On 4/23/12, Jen-Lung Chiu wrote:
>> Please run the app under debugger and check which dbgeng.dll and
>> dbghelp.dll the app loads. Depend on where you expect the
>> ntdll.dll/ntdll.pdb being loaded from, please verify whether the app
>> could load symsrv.dll
>>
>>________________________________________
>> From: xxxxx@lists.osr.com
>> [xxxxx@lists.osr.com]
>> on behalf of raj_r [xxxxx@gmail.com]
>> Sent: Sunday, April 22, 2012 4:01 AM
>> To: Kernel Debugging Interest List
>> Subject: [windbg] IDebugSymbols Methods Failing With E_UNEXPECTED
>> (0x8000ffff)
>>
>> for the past some days i was dabbling in the engextcpp/dbgeng model
>> and trying to shed the fear of COM
>>
>> i am trying to make standalone exes and not debug extensions (ala
>> dumpchk
>> style)
>> i made a few POCS and they seem to work ok which you can check here
>>
>> http://social.msdn.microsoft.com/Forums/en-US/windbg/thread/30a6c8e3-1
>> 8a9-4516-a732-46f8f64d1496
>>
>> http://social.msdn.microsoft.com/Forums/en-US/windbg/thread/8460d6c1-b
>> 5d3-4882-98d7-9a71eb4c53c9
>>
>> now i am trying to read and write a few symbol info and it seems all
>> the IDebugSymbols Methos fails with E_UNEXPECTED
>>
>> is there some preparatory step that needs to be accomplished prior to
>> calling IDebugSymbol Methods ?
>>
>> a sample snippet and its output as follows
>>
>>
>>
>> if ( ( status = g_Symbols->GetSymbolTypeId(
>>
>> ântdll!_GUIDâ,
>>
>> &TypeId,
>>
>> &ModuleInfo
>>
>> ) ) != S_OK ) {
>>
>> printf(âg_Symbols GetSymbolTypeId Failed With
>> %x\nâ,status);
>>
>> return 0;
>>
>> } else {
>>
>> printf(
>> âg_Symbols GetSymbolTypeId Succeded returned %x\nâ
>> âLoadedModules %x\nâ
>> âUnloaded modules %x\nâ,
>> status,
>> TypeId,
>> ModuleInfo
>> );
>>
>> }
>>
>>
>> F:\dumpsym>objfre_wxp_x86\i386\DumpSym.exe
>>
>> Debug Create Succeded returned 0
>> Query Interface IDebugControl Succeded returned 0 Query Interface
>> IDebugSymbols Succeded returned 0 SetOutPutCallBacks Succeded returned
>> 0
>>
>> g_Symbols GetSymbolTypeId Failed With 8000ffff
>>
>> F:\dumpsym>err 8000ffff
>> Query: 8000ffff
>>
>> 0x8000FFFF E_UNEXPECTED
>> Catastrophic failure.
>>
>>
>> F:\dumpsym>echo thanks to Daniel @ resplendence i mad a bat file and
>> place it in path
>>
>> F:\dumpsym>type c:\WINDOWS\err.bat
>> @echo off
>> c:\mybattools\errorlookup\errorlookup.exe %1 /noheader F:\dumpsym>
>>
>> â
>> 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
>>
>> â
>> 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
>>
>
> â
> 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
>
>
>
> â
> 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
>