After a bit of searching I stumbled upon windbg and process explorer. This is fun but out of my league. There is lots information on windbg but I could sure use some help. I feel like muggle with a wand.

windbg stack after answering "Proceed with Format (Y/N)?" is
0:002> ~*
   0  Id: 5bc.ce0 Suspend: 1 Teb: 7ffdf000 Unfrozen
      Start: format!mainCRTStartup (010067ea)
      Priority: 0  Priority class: 32  Affinity: f
   1  Id: 5bc.fac Suspend: 1 Teb: 7ffde000 Unfrozen
      Start: kernel32!BaseThreadStartThunk (77e617ec)
      Priority: 0  Priority class: 32  Affinity: f
.  2  Id: 5bc.d34 Suspend: 1 Teb: 7ffdd000 Unfrozen
      Start: ntdll!DbgUiRemoteBreakin (7c83fdb4)
      Priority: 0  Priority class: 32  Affinity: f
0:001> ~0s
ntdll!KiFastSystemCallRet:
7c8285ec c3              ret
0:000> k
ChildEBP RetAddr
0006f748 7c82776b ntdll!KiFastSystemCallRet
0006f74c 77e418b2 ntdll!NtReadFile+0xc
0006f7b4 71f8b9ba kernel32!ReadFile+0x16c
0006f7dc 71f84ea8 ulib!PIPE_STREAM::FillBuffer+0x3c
0006f820 71f8523c ulib!BUFFER_STREAM::GetBuffer+0x30
0006f898 71f8c72c ulib!BUFFER_STREAM::ReadString+0x44
0006f8d4 71f8c857 ulib!STREAM_MESSAGE::ReadLine+0x5c
0006f934 01005b8c ulib!STREAM_MESSAGE::IsYesResponse+0x70
0006ff44 01006919 format!main+0x992
0006ffc0 77e6f23b format!mainCRTStartup+0x12f
0006fff0 00000000 kernel32!BaseProcessStart+0x23
0:002> ~1s
ntdll!KiFastSystemCallRet:
7c8285ec c3              ret
0:001> k
ChildEBP RetAddr
0067fea0 7c827cfb ntdll!KiFastSystemCallRet
0067fea4 7c80e5bb ntdll!NtWaitForMultipleObjects+0xc
0067ff48 7c80e4a2 ntdll!EtwpWaitForMultipleObjectsEx+0xf7
0067ffb8 77e64829 ntdll!EtwpEventPump+0x27f
0067ffec 00000000 kernel32!BaseThreadStart+0x34t


I am unable to step into ~0 without hitting the hang.

I am able to trace into ~1 after waiting a bit for the initial step to complete. ~1 seems to be spinning un-checked. I see what seems to be a regular repeated pattern of cmds here.

Process Explorer prior to "Proceed with Format (Y/N)?" PE shows the that the thread stack is:
   format.com+<address>
   ntdll.dll!RtlSetLastWin32ErrorAndNtStatusFromNtStatus+0x59

After answering (Y/N)? ntdll.dll! goes away.

No new threads start and the format stack does not change. The state continues to be Wait:Executive and no user or kernel time accumulates. Am I missing the thread seen in windbg or am I stuck in the kernel somewhere?

Blah! Does anyone have context in this area that might help?

Thanks

-srp

Robert Pendell wrote:
I meant that for some reason format.com wasn't sufficient. It was formatted but not really. Kinda hard toxplain. It wasn't until I used disk management to do it that it was ok. The environment I used should be equivalent to a real machine.

srp wrote:
Thanks for your effort Robert. I was hoping that my Cygwin environment was somehow to blame.

What did you mean that formatting alone was not sufficient? I was able to read and write to the drive once the format was complete.

-srp

Robert Pendell wrote:
srp wrote:
Thanks Larry.  Version Updated.  1.5.24 is correct.

You WAG wrong however. Once the Volume has been formated in a native Cygwin window I can format successfully via SSH and all output is displayed.

With a newly created tiny volume the hang last in excess of an hour and should complete in second.

-srp


Ok. I have a couple of Virtual Machines setup here for testing purposes and such so I setup a cygwin install on the XP one (snapshot before hand so it can revert back clean) and installed a base cygwin setup with openssh. Then I installed the server and set it up as a service. I also turned off the firewall on it (no one can access it outside of the network anyways). I did not do anything special but it has 2 virtual hard drives to it. A 1 GB one was added to the virtual machine and I created one unformatted partition that did not have any particular partition type setup. Therefore it just showed up as RAW for now. I then had to format it but I tried this via SSH.

It got stuck right after the line that shows "Proceed with Format (Y/N)?" same as the OP. The same command worked fine once I formatted the partition locally via Disk Management. This does not appear to be a WAG (lack of tty support) issue though as this partition formats quickly (under 10 seconds) when done locally but I waited at least a minute for it to complete without success. Please note that formatting using the format command locally wasn't sufficient. It had to be done via Disk Management for some reason. Both quick formats and regular formats got stuck. Format.com is listed in the processes during this with zero activity and no disk activity is being reported by the Virtual Machine. Last but not least once it is formatted via Disk Management it works fine via a SSH session with all output coming back on the tty.

My own cygcheck.out is attached here.

Operating System: Windows XP SP2 (all updates installed)
Cygwin Version: 1.5.24 (latest)
Stock install with only openssh (+ dependencies) and nano installed

Any tests you want me to do I am more than willing to. The environment is there to test out scenarios.

Robert Pendell


------------------------------------------------------------------------

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Reply via email to