I built a kernel driver and loaded it. I checked that its private pdb file had been loaded correctly. Yet I could not set breakpoints on certain valid lines.
What is more weird, After I hit F9, WinDBG should set a breakpoint at an irrelevant address such as “75363275 0001 (0001) ole32!wGetEnumFormatEtc”.
The real report was as follows:
kd> !lmi swapbuffers
Loaded Module Info: [swapbuffers]
Module: SwapBuffers
Base Address: 9d8dd000
Image Name: SwapBuffers.sys
Machine Type: 332 (I386)
Time Stamp: 50c155d5 Fri Dec 07 10:35:01 2012
Size: 26000
CheckSum: 309a5
Characteristics: 102
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 65, 22e10, 21e10 RSDS - GUID: {592E4741-2410-4961-84B6-16EFE442ED6F}
Age: 1, Pdb: d:\yaoxin\works\solutions\netwall\nwkernel\objchk_win7_x86\i386\nwkernel.pdb
?? 10, 22e78, 21e78 [Data not mapped]
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol search path.
d:\symbols\private\nwkernel.pdb
Compiler: C++ - front end [17.0 bld 50727] - back end [17.0 bld 50727]
Load Report: private symbols & lines, not source indexed
d:\symbols\private\nwkernel.pdb
kd> bl
0 e 75363275 0001 (0001) ole32!wGetEnumFormatEtc
your output looks odd
you seem to be looking for swapbuffers and the output shows nwkernel
also !lmi isnt recommended in docs (i remember gettting an error
always when i used it in usermode like cannot find process
… iirc it is broken
try doing lm m swapbuffers
and on the start address of module use !dh to read the headers
0:000> lm m ftintandfsqrt
start end module name
00400000 00406000 ftintandfsqrt (private pdb symbols)
C:\Documents and Settings\Admin\my documents\visual studio
2010\Projects\ftintandfsqrt\Release\ftintandfsqrt.pdb
0:000> !dh 00400000
Debug Directories(1)
Type Size Address Pointer
cv 89 2108 708 Format: RSDS, guid, 2b,
c:\documents and settings\admin\my documents\visual studio
2010\Projects\ftintandfsqrt\Release\ftintandfsqrt.pdb
On 12/7/12, xxxxx@gmail.com wrote: > I built a kernel driver and loaded it. I checked that its private pdb file > had been loaded correctly. Yet I could not set breakpoints on certain valid > lines. > > What is more weird, After I hit F9, WinDBG should set a breakpoint at an > irrelevant address such as “75363275 0001 (0001) ole32!wGetEnumFormatEtc”. > > The real report was as follows: > > kd> !lmi swapbuffers > Loaded Module Info: [swapbuffers] > Module: SwapBuffers > Base Address: 9d8dd000 > Image Name: SwapBuffers.sys > Machine Type: 332 (I386) > Time Stamp: 50c155d5 Fri Dec 07 10:35:01 2012 > Size: 26000 > CheckSum: 309a5 > Characteristics: 102 > Debug Data Dirs: Type Size VA Pointer > CODEVIEW 65, 22e10, 21e10 RSDS - GUID: > {592E4741-2410-4961-84B6-16EFE442ED6F} > Age: 1, Pdb: > d:\yaoxin\works\solutions\netwall\nwkernel\objchk_win7_x86\i386\nwkernel.pdb > ?? 10, 22e78, 21e78 [Data not mapped] > Image Type: MEMORY - Image read successfully from loaded memory. > Symbol Type: PDB - Symbols loaded successfully from symbol search > path. > d:\symbols\private\nwkernel.pdb > Compiler: C++ - front end [17.0 bld 50727] - back end [17.0 bld > 50727] > Load Report: private symbols & lines, not source indexed > d:\symbols\private\nwkernel.pdb > kd> bl > 0 e 75363275 0001 (0001) ole32!wGetEnumFormatEtc > > > Any help? > > — > 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 >
Is the code compiled optimized or unoptimized?
joe
I built a kernel driver and loaded it. I checked that its private pdb file
had been loaded correctly. Yet I could not set breakpoints on certain
valid lines.
What is more weird, After I hit F9, WinDBG should set a breakpoint at an
irrelevant address such as “75363275 0001 (0001) ole32!wGetEnumFormatEtc”.
The real report was as follows:
kd> !lmi swapbuffers
Loaded Module Info: [swapbuffers]
Module: SwapBuffers
Base Address: 9d8dd000
Image Name: SwapBuffers.sys
Machine Type: 332 (I386)
Time Stamp: 50c155d5 Fri Dec 07 10:35:01 2012
Size: 26000
CheckSum: 309a5
Characteristics: 102
Debug Data Dirs: Type Size VA Pointer
CODEVIEW 65, 22e10, 21e10 RSDS - GUID:
{592E4741-2410-4961-84B6-16EFE442ED6F}
Age: 1, Pdb:
d:\yaoxin\works\solutions\netwall\nwkernel\objchk_win7_x86\i386\nwkernel.pdb
?? 10, 22e78, 21e78 [Data not mapped]
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from symbol search
path.
d:\symbols\private\nwkernel.pdb
Compiler: C++ - front end [17.0 bld 50727] - back end [17.0 bld
50727]
Load Report: private symbols & lines, not source indexed
d:\symbols\private\nwkernel.pdb
kd> bl
0 e 75363275 0001 (0001) ole32!wGetEnumFormatEtc
One reason you may have this issue is that the compiler does not always generates the code you think it should. One obvious situation is if the code it #ifdef’ed out (it will be really reimbursing if this is it) but today’s compilers are not generating code which is never called. This happens most often for overloaded C++ functions and methods (especially in tampletized code).
To check, use the display symbol information (“x funct_name”) command in WinDBG. For templates you may have to use wildcards since the symbol names a horrifically mangled (e.g. “x *funct_name*”).
-Uri
> One reason you may have this issue is that the compiler does not always
generates the code you think it should. One obvious situation is if the
code it #ifdef’ed out (it will be really reimbursing if this is it) but
today’s compilers are not generating code which is never called. This
happens most often for overloaded C++ functions and methods (especially in
tampletized code).
To check, use the display symbol information (“x funct_name”) command in
WinDBG. For templates you may have to use wildcards since the symbol names
a horrifically mangled (e.g. “x *funct_name*”).
-Uri
And in optimized code, some functions are automatically inlined instead of
being called; code motions outside loops and branches mean that line 122
might be executed before line 110, even though the source code suggests
otherwise. Optimizied code does not usually have a good correspondence to
source lines, because some code disappears, other code moves, there is
inlining, and, oh yes, the handling of destructors in C++ introduces odd
code flows.
I was developing a course in how to read optimized compiler code when
health issues forced my early retirement. The modern 32-bit compiler is
awesome, but the 64-bit compiler is even more awesome (I once worked on
what was one of the world’s very best optimizing compilers, and it held
that position even after the machines that hosted it were no longer
manufactured. But the Microsoft compilers really put it into perspective:
we were doing trivial-by-comparison optimizations. No automatic inlining,
for example.
joe
>> One reason you may have this issue is that the compiler does not always
> generates the code you think it should. One obvious situation is if the
> code it #ifdef’ed out (it will be really reimbursing if this is it) but
> today’s compilers are not generating code which is never called. This
> happens most often for overloaded C++ functions and methods (especially
> in
> tampletized code).
> To check, use the display symbol information (“x funct_name”) command in
> WinDBG. For templates you may have to use wildcards since the symbol
> names
> a horrifically mangled (e.g. “x *funct_name*”).
> -Uri
I forgot to add another misfeature of compiler/debugger interactions with
optimized code. Suppose you set a breakpoint at line 110 in your source
file. That is remembered as a breakpoint on line 110 of the source file.
If you modify the source file so it is now line 109 or line 111, you still
get a breakpoint on whatever is line 110. In the case of an optimizing
compiler, a minor, perhaps trivial, source change may break an existing
optimization or enable a new one. So the correspondence of line numbers
to instruction locations is now changed, just by the way in which code is
generated. This can lead to discontinuities in breakpoint rendering.
joe
And in optimized code, some functions are automatically inlined instead of
being called; code motions outside loops and branches mean that line 122
might be executed before line 110, even though the source code suggests
otherwise. Optimizied code does not usually have a good correspondence to
source lines, because some code disappears, other code moves, there is
inlining, and, oh yes, the handling of destructors in C++ introduces odd
code flows.
I was developing a course in how to read optimized compiler code when
health issues forced my early retirement. The modern 32-bit compiler is
awesome, but the 64-bit compiler is even more awesome (I once worked on
what was one of the world’s very best optimizing compilers, and it held
that position even after the machines that hosted it were no longer
manufactured. But the Microsoft compilers really put it into perspective:
we were doing trivial-by-comparison optimizations. No automatic inlining,
for example.
joe
Almost invariable if windbg sets a breakpoint at the wrong location in the
source code that is because you have windbg pointed at the right symbols
but the wrong source. This can happen if you have multiple versions of the
source and you’ve seet the source path to the wrong place, or if the image
is old and the source is new.
Mark Roddy
On Sat, Dec 8, 2012 at 10:28 PM, wrote:
> > One reason you may have this issue is that the compiler does not always > > generates the code you think it should. One obvious situation is if the > > code it #ifdef’ed out (it will be really reimbursing if this is it) but > > today’s compilers are not generating code which is never called. This > > happens most often for overloaded C++ functions and methods (especially > in > > tampletized code). > > To check, use the display symbol information (“x funct_name”) command in > > WinDBG. For templates you may have to use wildcards since the symbol > names > > a horrifically mangled (e.g. “x funct_name”). > > -Uri > > And in optimized code, some functions are automatically inlined instead of > being called; code motions outside loops and branches mean that line 122 > might be executed before line 110, even though the source code suggests > otherwise. Optimizied code does not usually have a good correspondence to > source lines, because some code disappears, other code moves, there is > inlining, and, oh yes, the handling of destructors in C++ introduces odd > code flows. > > I was developing a course in how to read optimized compiler code when > health issues forced my early retirement. The modern 32-bit compiler is > awesome, but the 64-bit compiler is even more awesome (I once worked on > what was one of the world’s very best optimizing compilers, and it held > that position even after the machines that hosted it were no longer > manufactured. But the Microsoft compilers really put it into perspective: > we were doing trivial-by-comparison optimizations. No automatic inlining, > for example. > joe > > > > > — > > 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 >