SOLVED Anyone getting Windbg to work for the latest build?

[Saltgrass]

I am getting BSODs for the new creator's build on one of my new Dell Systems. I think it is related to Netwtw04.sys, which is an Intel Wireless driver. I have replaced the driver with a newer version which seems to have stopped the Blue Screens but I am having problems getting Windbg to function correctly.

I downloaded the new Windbg (15063) and the symbols for it but I keep getting errors when I run it. Does anyone know if it should be working normally or might some switch need to be thrown after the public release?

Thanks..

 

[Trouble]

Hadn't updated my WinDbg until your post.
Just uninstalled my previous version and went out and got it from the latest SDK
Version 10.0.15063.137
Tested and seems to work OK on some older dump files I have stored on my computer, but....
I don't suspect that anything I have is from a crash of the latest version of Windows 10.
Maybe zip up one of yours and attach it and I'll test and see if I get any errors.

 

[Saltgrass]

Thanks, Trouble, I will attach the files. I may be having permissions problems since I had to change permissions on the dump files to even send them to a .Zip file. I also get multiple "GetContextState failed,0x800700iE" errors, which mean:

ERROR_READ_FAULT
30 (0x1E)
The system cannot read from the specified device.

This may be related to McAfee, which comes on the system from Dell. Possibly some type of Read permissions which is what I saw when I had to change the permissions on the dump files...

 

[Trouble]

OK.....
Got a bunch of nonsense regarding my symbol path.
Which I know is an error because, I can delete my entire cache directory and fire up a couple dump files and it will begin to replenish as need to debug the dump file.
I've seen this before when the builds got ahead of
http://msdl.microsoft.com/download/symbols
which is the source for my local symbol cache, full path = SRV*D:\SymCache*http://msdl.microsoft.com/download/symbols

So I went to the horse's mouth and downloaded the full package after emptying my local cache again.
https://developer.microsoft.com/en-us/windows/hardware/download-symbols

Same error
So either there is something wrong with your dump files (all 4 which is sort of unlikely) or there is something wrong with the current symbols available.

I did notice that your dump files were all over a meg in size and typically I see them closer to half a meg or less, so.....
First make sure your machine is configured properly to facilitate the collection of .dmp files.

Go to Start and type in sysdm.cpl and press Enter
Click on the Advanced tab
Click on the Startup and Recovery Settings button
Ensure that Automatically restart is unchecked
Under the Write Debugging Information header select Small memory dump (256 kB) in the dropdown box
Ensure that the Small Dump Directory is listed as %systemroot%\Minidump << where your .dmp files can be
found later.
Click OK twice to exit the dialogs, then reboot for the changes to take effect.

See if that produces anything that we might be able to get something from.

 

[Saltgrass]

I have a Memory.dmp file which is 1 GB in size. Possibly the process isn't working correctly and padding the data. My system is set up for 256K files. I had maybe 5 BSODs prior to replacing the driver. If you don't have the system set up for the small files, will there even be a minidump folder?

I have tried the Symbols for the new build and the ones for the Preview. Since I always seem to have problems setting up the symbols, I figured it was my fault, and it may still be.

I'll keep working on it, possibly when they throw the switch on the public release, something may change. Otherwise, I seem to have the access problem I need to figure out.

Luckily, I haven't had another BSOD since I changed that driver.

Thanks again.

 

[Trouble]

If you don't have the system set up for the small files, will there even be a minidump folder?

Nope. You're absolutely right there wouldn't be.

 

[Saltgrass]

I am finally able to read those dump files. They were not corrupted, just the symbols were not loading correctly.

Whether Microsoft repaired the problem or my having run a couple of 14393 files for analysis, I don't know.. but it is working now.

 

[Saltgrass]

It seems I have only been able to get the Windbg to work on my dump files. The same errors show up for files from other systems.

And we still do not know why the mini-dump files are so large... I can still analyze files from 14393 without problems.

It was suggested I run the !sym noisy; .reload /f nt (or nt.dll) command to see if the symbols are loading and it runs normally with 14393 files but same errors and no available in 15063.

I am fairly sure it is not my error right now, unless there was some change regarding how the debugger needs to be installed.

 

[Trouble]

I am fairly sure it is not my error

I'm pretty sure you're right, although I still don't have a clue what's up with the debugger or the available symbols.
Sooner or later someone will figure it out.

 

[Saltgrass]

I put a debugging session of a file I could analyze and one I could not. The good file was mine and the bad one was from a forum.

If we could figure out why one got a 1E error and the other did not, might help. As far as i can tall, both files have the same permissions. It is funny, my files originally gave me the same errors but no longer do...

0: kd> !sym noisy; .reload /f nt
noisy mode - symbol prompts on
SYMSRV: BYINDEX: 0x11
c:\symcache*https://msdl.microsoft.com/download/symbols
ntoskrnl.exe
58DEE9F6889000
SYMSRV: PATH: c:\symcache\ntoskrnl.exe\58DEE9F6889000\ntoskrnl.exe
SYMSRV: RESULT: 0x00000000
DBGHELP: c:\symcache\ntoskrnl.exe\58DEE9F6889000\ntoskrnl.exe - OK
DBGENG: c:\symcache\ntoskrnl.exe\58DEE9F6889000\ntoskrnl.exe - Mapped image memory
SYMSRV: BYINDEX: 0x12
c:\symcache*https://msdl.microsoft.com/download/symbols
ntkrnlmp.pdb
6EFC00DDC5A54F148CED4662F4A27F8D1
SYMSRV: PATH: c:\symcache\ntkrnlmp.pdb\6EFC00DDC5A54F148CED4662F4A27F8D1\ntkrnlmp.pdb
SYMSRV: RESULT: 0x00000000

DBGHELP: nt - public symbols
c:\symcache\ntkrnlmp.pdb\6EFC00DDC5A54F148CED4662F4A27F8D1\ntkrnlmp.pdb

------------------------------------------------------------------------------------------
0: kd> !sym noisy; .reload /f nt
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
Unable to get program counter
noisy mode - symbol prompts on
SYMSRV: BYINDEX: 0x59
c:\symcache*https://msdl.microsoft.com/download/symbols
ntoskrnl.exe
58DEE9F6889000
SYMSRV: PATH: c:\symcache\ntoskrnl.exe\58DEE9F6889000\ntoskrnl.exe
SYMSRV: RESULT: 0x00000000
DBGHELP: c:\symcache\ntoskrnl.exe\58DEE9F6889000\ntoskrnl.exe - OK
DBGENG: c:\symcache\ntoskrnl.exe\58DEE9F6889000\ntoskrnl.exe - Mapped image memory
SYMSRV: BYINDEX: 0x5A
c:\symcache*https://msdl.microsoft.com/download/symbols
ntkrnlmp.pdb
6EFC00DDC5A54F148CED4662F4A27F8D1
SYMSRV: PATH: c:\symcache\ntkrnlmp.pdb\6EFC00DDC5A54F148CED4662F4A27F8D1\ntkrnlmp.pdb
SYMSRV: RESULT: 0x00000000

DBGHELP: nt - public symbols
c:\symcache\ntkrnlmp.pdb\6EFC00DDC5A54F148CED4662F4A27F8D1\ntkrnlmp.pdb
GetContextState failed, 0x8007001E
Unable to get current machine context, Win32 error 0n30
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E

--------------------------------------------------------------------------------------------
ERROR_READ_FAULT30 (0x1E)
The system cannot read from the specified device.

 

[Trouble]

Well my debugger magically started working again on the three dump files you attached earlier.
On the one 040917-8343-01.dmp

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.

With mention of

Probably caused by : Netwtw04.sys
SYMBOL_NAME: Netwtw04+4f5c2
MODULE_NAME: Netwtw04
FAILURE_BUCKET_ID: AV_Netwtw04!unknown_function
BUCKET_ID: AV_Netwtw04!unknown_function
PRIMARY_PROBLEM_CLASS: AV_Netwtw04!unknown_function

And when I look at the back trace that particular driver is mentioned multiple times.

On the other two I get the same

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000108, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff80bacf5f5c2, address which referenced memory
Probably caused by : Netwtw04.sys ( Netwtw04+4f5c2 )

But I do see a lot of the

GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E
GetContextState failed, 0x8007001E

AND when I look at the back trace, there are a lot of holes but, I do see a mention of

ffffb101`f66e7e10 fffff80b`a875c1b0 tcpip!UdpTlProviderIoControlEndpoint
ffffb101`f66e7e18 fffff80b`a90f312d afd!AfdTLIoControl+0x9d
ffffb101`f66e7e20 ffffc60f`137e2000
ffffb101`f66e7e28 fffff80b`a7f52e98 NETIO!FsbFree+0x68
ffffb101`f66e7e30 ffffc60e`ff9aa6e0
ffffb101`f66e7e38 fffff80b`a7f52e30 NETIO!FsbFree

Which I would typically associate with some type of network issue, maybe an adapter driver of possibly an over zealous piece of security software.

It's important to note that prior to this I was not able to debug any of your dump files as I only received a lot of complaints from the debugger about symbols
AND
Only on your dump files, as older dump files that I have stored locally debugged just fine with no complaints regarding symbols
So I assume that the Microsoft Symbol server is now working or at least now working better.

 

[Saltgrass]

I noticed mine starting working normally, no errors, a couple of weeks ago. I had already changed out that driver and have not had a Blue Screen since.

The comments about not being able to get the system status, I assume is referring from something it is supposed to get from the dump file.... That would seem to tie into the "Unable to Read" type messages but it does seem like some type of access situation. It may not be a symbol server but the fact the debugger cannot gain access to the dump file..

An the size of the file, which you mentioned earlier, could be involved. The other file I am looking at now is a 1.3 MB mini-dump file. Maybe there is a problem with the new build and how it creates dump files.

I have to wonder how Microsoft is analyzing dump files if these errors are happening with us.

I will keep investigating so thanks for the help..

 

[louis14]

hi saltgrass,
are you still getting errors when analazing minidumpfiles created after the creators update?
since i've upgraded my laptop with the creators update i cannot analyze anymore my minidumpfiles which are created after the creators update

 

[Saltgrass]

hi saltgrass,
are you still getting errors when analazing minidumpfiles created after the creators update?
since i've upgraded my laptop with the creators update i cannot analyze anymore my minidumpfiles which are created after the creators update

Yes, still the same problems with symbols and possibly the size of the dump files. So really not sure if it is just the symbols.

I have one dump file which seems to analyze normally but when I check the modules the dates show from 2027 to 1970.

 

[louis14]

I have tried an old version (windows 8) of windbg and that works

 

[Saltgrass]

I have tried an old version (windows 8) of windbg and that works

The latest debugger works fine with earlier versions of a dump file, such as 14393. It just won't work with the latest build. I have not tried an earlier debugger with the later dump files but if I get any more I might do that..

Thanks..