Planning the Future of Privacy at Microsoft 138
Tony writes "Peter Cullen, Microsoft's chief privacy strategist, found himself in the front line in the wake of the software giant's recent antipiracy controversy. He talks about his role at the company, and what's in store for the future." From the interview: "Cullen, Microsoft's chief privacy strategist, has been very involved with the issue and readily admits that the software maker dropped the ball on WGA Notifications. The flap puts him on the front line, rather than his usual role behind the scenes. For the most part, Cullen, who joined Microsoft three years ago from the Royal Bank of Canada in Toronto, is happy with his role at the software giant. He works on things such as guidelines for developers and privacy policies."
Re:Off topic, but... (Score:3, Informative)
I tried it probably a dozen times.
Each and every single time it came back telling me there was no additional information. I turned it off. (System Control Panel -> Advanced -> Error Reporting -> Disable Error Reporting for those that might not know how.)
I don't miss it.
RBC != SCO investor (Score:3, Informative)
Re:Off topic, but... (Score:5, Informative)
If you have memory dumps turned on (My Computer, Properties, Advanced, Startup and Recovery Settings, Write debugging information, Small Memory Dump (or better)), you do get to see the error message. That error message is embedded in the created dump file. In order to see what process or driver faulted the system (the error message), you take that dump file and run it through WinDbg. WinDbg is part of the "Debugging Tools for Windows" package, a free download from Microsoft.
When you say "Send it" to Microsoft, what happens is that the equivalent of a small dump file is sent to Microsoft for automated analysis. WinDbg uses basically the same analysis engine. Assuming whatever crashed your system didn't totally corrupt memory and your stack, WinDbg will tell you what process, processor, and what thread caused the fault. It will also take a good stab at what module (dll, sys file, etc.) was responsible for the fault. If you have enough symbolic information available you may even get a function or stack frame name that is of use.
Mark Russinovich has a book Microsoft Windows Internals, Fourth Edition: Microsoft Windows Server(TM) 2003, Windows XP, and Windows 2000 that has useful information about all this.