Hey, thanks for the suggestions!
Turns out the problem seems to have been a cascade of independent issues.
lmv revealed that the mysterious blank-named module was in fact ntdll.dll.
Who knows why it was being misrepresented, but that was an easy fix.
However, that was not in fact the root problem. !sym noisy revealed a huge
amount of symbol loading activity during startup – that itself was what was
slowing bootup to a crawl. Somehow, deferred symbol loading had gotten
disabled, and so symbols for all modules were being loaded, which resulted
in the new error messages about symbols for modules we’d never before
touched. Reinstalling windbg didn’t help, but a mixture of wild flailing and
clearing the workspace settings seemed to. And, why were symbols for
NTOSKRNL screwed up? Who knows. They aren’t anyomre. *shrugs*
So, all’s well again, despite the strange nature of the problems. Thanks!
(Sorry about the delay in responding, BTW. Shortly after I made my original
post, computer support in its infinite wisdom marched in and walked off with
all our workstations, and our code server! Of course, they didn’t ask us, or
our supervisors, and they didn’t tell us either. Apparently they presumed
that this office wasn’t in use. Not only that, but the plan was to
immediately wipe them and set them up for another purpose elsewhere! Thank
god we caught them in time… but not before they’d moved them to another
room with a few dozen identical-looking computers, through which we had to
dig through on Christmas morning. Sheesh. Needless to say, things were a bit
disrupted for a while, and the sick workstation wasn’t in use. =P )
–Micah Brodsky
“Scott Noone” wrote in message news:xxxxx@windbg…
> Hi,
>
> Don’t know what’s going on with the blank file name, but I can tell you
> that the “dump_” drivers aren’t nonexistent. During boot Windows makes
> copies of the core storage stack drivers and specially loads them with the
> “dump_” prefix. They’re used to write out the crash dump file in the case
> of a BSOD. You might also see “hiber_” drivers if you have hibernation
> enabled.
>
> Only other things I can think of would be trying:
>
> 1) The latest WinDBG
> 2) ‘!sym noisy’ and then a ‘.reload’. This might give you a better clue as
> to what’s going on
> 3) ‘lmv’ will show you all of the loaded images and their timestamps, so
> maybe you can find your mystery file that way
> 4) Delete your local symbol store and refresh from the symbol server
>
> Regards,
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “Micah Brodsky” wrote in message
> news:xxxxx@windbg…
>> Hi,
>>
>> I’ve been having some really wierd problems that spontaneously appeared
>> recently with WinDBG (6.2.0013.0) on one of my development machines,
>> debugging a Win2k installation. During startup, not too long after the
>> initial breakpoint, WinDBG prints the message "*** WARNING: symbols
>> timestamp is wrong 0x38175b30 0x41c77180 for ". Yes, blank for the
>> filename. Then, startup proceeds incredibly slowly, with a number of
>> other symbols errors including some for nonexistent files (“dump_”
>> prepended to real driver filenames). I’ve tried doing fresh rebuilds of
>> all the components we’ve been working on (including NTOSKRNL) and copying
>> them over onto a clean test system installation, but no change. Any ideas
>> what might be going on? Or, any idea how to identify the mysterious
>> blank-named file, perhaps by its timestamp?
>>
>> Thanks a lot.
>> --Micah Brodsky
>>
>>
>
>
>