> Debugging is tricky unless you have experience with how to debug > assembler code and know a bit about x86/AMD64 assembler and how to use > WinDbg. A high level of capacity for suffering might help, too ;) It's > not a lot of code you would have to look at, basically just the first > 100 or so bytes within two functions in ntdll.dll are affected. If > you're basically comfortable with that, we could arrange a debugging > session via IRC (Freenode).
I don't have much experience, but I know enough assembly to read it and to do basic debugging. I haven't used WinDbg before, but I've used other disassemblers as well as GDB. I'm willing to do this if someone can let me know what I should be looking at/for. > The other choice is not to debug, but trying to find out what Windows > Update or what software package introduced the problem. This is not > overly tricky, but could take lots of hours and needs lots of patience. > You would have to deinstall Windows Updates, reboot, try again, > re-install, remove other Windows Updates, try again... up to the point > where the find_fast_cwd message disappears. Also, software packages > like virus scanners, firewalls, and especially Microsoft software could > have introduced the problem and deinstalling and later reinstalling > might do the trick.,. and then I would have to install the culprit and > debug the problem myself. I'll do this if I (really, really) have to. As you say, this will take some time, largely in rebooting, and that's just assuming it's Windows Update and not another program. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
