i want to *disable* os symbols from loading in windbg. simply removing the
symbol server path, or the local sym store path is not enough. i want windbg
to completely ignore all os modules, and stop searching for their symbols
before dumping ‘symbol not laoded’. it slows the process of debugging, and
when i am pretty the issue wis with my driver i want to bypass the long
*BUSY* status…
Why do you want to do this exactly? It sounds like you’re trying to improve the responsiveness of windbg, which can be a little slow sometimes.
That being said, debugging without symbols is a lot slower than waiting for windbg.
If this is your major issue, then there are a few things I would recommend trying before abandoning ship, as it were.
In order to get windbg to ignore any symbol path that might be pulled from _NT_SYMBOL_PATH, you have to specify ‘-sins’ on the command line; once windbg is running, it doesn’t check it again, so (apparently) .symopt-+0x1000 won’t do it.
Read up on ‘.symopt.’
In particular, you might want to consider trying some combination of:
I have to believe that windbg will require at least symbols/exports for nt to function correctly. Further, I think you’ll find that lots of extensions will fail without certain symbols.
Why do you want to do this specifically? That is, what’s the scenario where you find yourself waiting? If you’re not qualifying your symbols (i. e. - dt _EPROCESS v. dt nt_EPROCESS), that’s a HUGE cause of delay, as are typos. That’s what adding SYMOPT_NO_UNQUALIFIED_LOADS should help address.
thanks for the details. well, the isue here is i am debugging a CRB for an
intel laptopboard, and it doesn’t have 1394. so I am forced to debug using
serial, which is slooooooooooooooooooooooooow
also, i find that the machine everytime takes 5 / 10 mins to pull down
symbols because it cannot find os symbols for the ms components 9though i
see them present in he disc), the same pbds are over written (yes over
written)
so i decided, as it doesnt concern my debug scenaroi most of te time, why
not, eliminate it.
thanks
ap
On Thu, Jul 30, 2009 at 12:31 PM, wrote:
> Why do you want to do this exactly? It sounds like you’re trying to > improve the responsiveness of windbg, which can be a little slow sometimes. > > That being said, debugging without symbols is a lot slower than waiting for > windbg. > > If this is your major issue, then there are a few things I would recommend > trying before abandoning ship, as it were. > > 1. In order to get windbg to ignore any symbol path that might be pulled > from _NT_SYMBOL_PATH, you have to specify ‘-sins’ on the command line; once > windbg is running, it doesn’t check it again, so (apparently) > .symopt-+0x1000 won’t do it. > > 2. Read up on ‘.symopt.’ > > In particular, you might want to consider trying some combination of: > > symopt+ 0x100 (SYMOPT_NO_UNQUALIFIED_LOADS) > symopt+ 0x8000 (SYMOPT_NO_PUBLICS) > symopt+ 0x20000 (SYMOPT_NO_IMAGE_SEARCH) > symopt- 0x04 (! SYMOPT_DEFERRED_LOADS) > > 3. > > I have to believe that windbg will require at least symbols/exports for nt > to function correctly. Further, I think you’ll find that lots of extensions > will fail without certain symbols. > > Why do you want to do this specifically? That is, what’s the scenario > where you find yourself waiting? If you’re not qualifying your symbols (i. > e. - dt _EPROCESS v. dt nt_EPROCESS), that’s a HUGE cause of delay, as are > typos. That’s what adding SYMOPT_NO_UNQUALIFIED_LOADS should help address. > > > > > mm > > — > 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 >
thanks for the details. well, the isue here is i am debugging a CRB for an intel laptopboard, and it doesn’t have 1394. so I am forced to debug using serial, which is slooooooooooooooooooooooooow
also, i find that the machine everytime takes 5 / 10 mins to pull down symbols because it cannot find os symbols for the ms components 9though i see them present in he disc), the same pbds are over written (yes over written)
so i decided, as it doesnt concern my debug scenaroi most of te time, why not, eliminate it.
thanks
ap
On Thu, Jul 30, 2009 at 12:31 PM, wrote:
Why do you want to do this exactly? It sounds like you’re trying to improve the responsiveness of windbg, which can be a little slow sometimes.
That being said, debugging without symbols is a lot slower than waiting for windbg.
If this is your major issue, then there are a few things I would recommend trying before abandoning ship, as it were.
1. In order to get windbg to ignore any symbol path that might be pulled from _NT_SYMBOL_PATH, you have to specify ‘-sins’ on the command line; once windbg is running, it doesn’t check it again, so (apparently) .symopt-+0x1000 won’t do it.
2. Read up on ‘.symopt.’
In particular, you might want to consider trying some combination of:
I have to believe that windbg will require at least symbols/exports for nt to function correctly. Further, I think you’ll find that lots of extensions will fail without certain symbols.
Why do you want to do this specifically? That is, what’s the scenario where you find yourself waiting? If you’re not qualifying your symbols (i. e. - dt _EPROCESS v. dt nt_EPROCESS), that’s a HUGE cause of delay, as are typos. That’s what adding SYMOPT_NO_UNQUALIFIED_LOADS should help address.
On Thu, Jul 30, 2009 at 4:26 PM, Scott Noone wrote:
> There is a way of saying, “don’t even load symbols for this module”. See: > > http://msdn.microsoft.com/en-us/library/cc901405.aspx > > MM’s suggestions might get you the desired results without going this far > though… > > -scott > > – > Scott Noone > Consulting Associate > OSR Open Systems Resources, Inc. > http://www.osronline.com > > > “A P” wrote in message news:xxxxx@windbg… > mm, > > thanks for the details. well, the isue here is i am debugging a CRB for an > intel laptopboard, and it doesn’t have 1394. so I am forced to debug using > serial, which is slooooooooooooooooooooooooow > > also, i find that the machine everytime takes 5 / 10 mins to pull down > symbols because it cannot find os symbols for the ms components 9though i > see them present in he disc), the same pbds are over written (yes over > written) > > so i decided, as it doesnt concern my debug scenaroi most of te time, why > not, eliminate it. > > thanks > > ap > > > On Thu, Jul 30, 2009 at 12:31 PM, wrote: > > Why do you want to do this exactly? It sounds like you’re trying to > improve > the responsiveness of windbg, which can be a little slow sometimes. > > That being said, debugging without symbols is a lot slower than waiting for > windbg. > > If this is your major issue, then there are a few things I would recommend > trying before abandoning ship, as it were. > > 1. In order to get windbg to ignore any symbol path that might be pulled > from _NT_SYMBOL_PATH, you have to specify ‘-sins’ on the command line; once > windbg is running, it doesn’t check it again, so (apparently) > .symopt-+0x1000 won’t do it. > > 2. Read up on ‘.symopt.’ > > In particular, you might want to consider trying some combination of: > > symopt+ 0x100 (SYMOPT_NO_UNQUALIFIED_LOADS) > symopt+ 0x8000 (SYMOPT_NO_PUBLICS) > symopt+ 0x20000 (SYMOPT_NO_IMAGE_SEARCH) > symopt- 0x04 (! SYMOPT_DEFERRED_LOADS) > > 3. > > I have to believe that windbg will require at least symbols/exports for nt > to function correctly. Further, I think you’ll find that lots of > extensions > will fail without certain symbols. > > Why do you want to do this specifically? That is, what’s the scenario > where > you find yourself waiting? If you’re not qualifying your symbols (i. e. - > dt _EPROCESS v. dt nt_EPROCESS), that’s a HUGE cause of delay, as are > typos. > That’s what adding SYMOPT_NO_UNQUALIFIED_LOADS should help address. > > > > > mm > > — > 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 >