tag:blogger.com,1999:blog-9977539741480046.post7241651645001504439..comments2024-02-09T23:27:37.645+11:00Comments on Zach Saw's Blog: WOW64 bug: GetThreadContext() may return stale contentsZach Sawhttp://www.blogger.com/profile/02019604928253273845noreply@blogger.comBlogger44125tag:blogger.com,1999:blog-9977539741480046.post-76923051461427478552014-07-03T18:41:40.827+10:002014-07-03T18:41:40.827+10:00So I'm a victim of this bug too; I have an app...So I'm a victim of this bug too; I have an application that wants to do both thread state inspection (e.g, what's in the registers including ESP) and thread hijacking.<br /><br />I don't mind being told (like the Magic 8 ball), "Situation hazy, try again later" but being told, "Sitation always hazy" is pretty bad news for XP/Vista/Windows7-64.<br /><br />Can somebody explain how 32 bit debuggers work on Windows64 boxes, given that the ReadThreadContext content isn't reliable? BREAKALL in the debugger is implemented using SuspendThread, right? If not, what method does the debugger use?<br /><br />I agree with Zack. Alexey was whining about not breaking existing applications and using that to justify not fixing the behavior of this... yet the problem is that MS's implementation breaks existing applications. He can't have it both ways; I think MS is simply being cheap. Worse, I think MS is saving money, having gotten ours, and worse, is costing us money because of something they were too cheap to fix. That's hardly what I call nice corporate behavior.Irahttps://www.blogger.com/profile/17434481929939406851noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-81582720558909798132014-04-01T22:52:32.574+11:002014-04-01T22:52:32.574+11:00Ah! Thank you so much for this very useful info! I...Ah! Thank you so much for this very useful info! I'll make sure to write something up to detail what exactly needs to be done. It'll be helpful for others facing the same problem. <br /><br />Still no solution for those OSes that don't support those extended flags though is there?Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-57223187032337802952014-04-01T18:37:39.681+11:002014-04-01T18:37:39.681+11:00I see what you are saying - you are performing man...I see what you are saying - you are performing manage type reference counting cross-thread instead of performing it in-thread after hijacking it.<br /><br />On native, GetThreadContext is always reliable. SetThreadContext requires those flags.<br /><br />On WoW, given that it is implemented in user-mode (and user mode can't block APCs and stuff) the context can be stale on short time windows when using hardware mode. As a work-around you could use those flags which should give you confidence that you are not in those dreadful windows.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-15841708093207886762014-04-01T16:08:13.830+11:002014-04-01T16:08:13.830+11:00Just another thing -- I'm not hijacking the th...Just another thing -- I'm not hijacking the thread. I'm merely relying on information returned via GetThreadContext for tracing managed pointers. I'm not touching the context in anyway, which is what hijacking typically means.Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-76265935424899551112014-04-01T16:06:13.850+11:002014-04-01T16:06:13.850+11:00Let me try to understand what you're saying.
...Let me try to understand what you're saying.<br /><br />On Windows XP, even in native 32-bit mode, we can't be certain that the context returned via GetThreadContext is correct? Since WinXP does not support CONTEXT_EXCEPTION_REQUEST, GetThreadContext is plain unreliable under XP and should be avoided completely?<br /><br />On Win7, even in native 32-bit mode, we need to check the CONTEXT_EXCEPTION flags before we assume the contents are correct. However, this doesn't work in WOW64 mode because it isn't supported.<br /><br />On Win8, CONTEXT_EXCEPTION flags are supported both under native 32-bit and WOW64 modes.<br /><br />Am I correct?Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-77767265459186862032014-03-31T19:27:24.816+11:002014-03-31T19:27:24.816+11:00Regardless. If you make sure you only hijack a thr...Regardless. If you make sure you only hijack a thread (which requires the execution of the SuspendThread, GetThreadContext and SetThreadContext) only when the flags say it is safe to do so, then the end goal should work just fine.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-78575157338859210732014-03-31T12:29:26.068+11:002014-03-31T12:29:26.068+11:00@Anonymous
The problem had nothing to do with Set...@Anonymous<br /><br />The problem had nothing to do with SetThreadContext. It was purely with GetThreadContext returning stale info. This problem continues to exist on Win8.1!Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-56397608959733440022014-03-29T14:36:24.937+11:002014-03-29T14:36:24.937+11:00Actually, since Windows 8, things should be workin...Actually, since Windows 8, things should be working well - and this applies to both native and simulated architectures by both software and hardware means.<br /><br />There are 4 obscure _CONTEXT flags that make hijacking reliable.<br /><br />You see, even for native, SuspendThread+GetThreadContext+SetThreadContext is not completely reliable. If the thread is, for some reason, in the kernel already at the time of SuspendThread for a syscall or a trap that could escalate to an exception, it may return to user-mode without some or any of the context SetThreadContext sets. An exception, for example, will overwrite the context completely to initiate Structured Exception Handling dispatch. For the Syscall case, one register will always reflect the NTSTATUS and all volatile registers are scrubbed.<br /><br />If you want a full-fidelity SetThreadContext, then you need to make sure SuspendThread catches the thread while running in user-mode.<br /><br />That's where those obscure variables kick-in.<br /><br />If you specify ctx->ContextFlags |= CONTEXT_EXCEPTION_REQUEST, you are asking the kernel to report back what were the circumstances that led the thread to enter kernel-mode.<br /><br />When GetThreadContext returns, you should look for the reply in the ContextFlags.<br /><br />If the kernel replies with CONTEXT_EXCEPTION_REPORTING set, it means that it understood the request (basically, that the OS supports, understands and is replying to the request). If this flag comes back 0, then it means that the OS does not support this.<br /><br />If it supports, result is specified thorugh 2 other flags:<br />CONTEXT_EXCEPTION_ACTIVE - if this comes back set, then the thread was already in the kernel, taking care of an trap (that could escalate to an exception). SetThreadContext is not a good idea.<br />CONTEXT_SERVICE_ACTIVE - if this comes back set, then the thread was already in the kernel, taking care of syscall. Once again, SetThreadContext is not a good idea.<br /><br />If these 2 flags come 0, then the thread entered the kernel for an interrupt. SetThreadContext is reliable - go ahead and hijack the thread.<br /><br />On Windows 7 these flags were supported for native threads but not simulated (WoW). On Windows 8 and posterior, these flags work on both Native and WoW threads.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-39815475207261924202014-03-29T11:46:49.247+11:002014-03-29T11:46:49.247+11:00@Anonymous
This is definitely very enlightening!
...@Anonymous<br /><br />This is definitely very enlightening!<br /><br />Sounds like they've implemented it correctly for ia64 but not x64!Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-74946828311216082962014-03-04T21:31:26.708+11:002014-03-04T21:31:26.708+11:00Actually that is not so. Intel only removed the ca...Actually that is not so. Intel only removed the capability to switch to x86 mode in ia64 after Madison. Till then the CPU was perfectly able to run x86 code without the need for any software emulation. After Madison, Intel removed that capability and introduced ia32el, an OS independent software emulator (with JIT) that was both successfully integrated in Windows and Linux. By the way, when WoW is running under software mode, on ia64, SuspendThread synchronizes with the simulator to make sure the call only returns after the WoW context has been updated in the TEB. Note that this synchronization is only performed if the thread calling SuspendThread and the target thread are in the same process. But then again that is always the case with these managed/GC run-time scenarios.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-48599013387477821122013-12-12T19:18:02.925+11:002013-12-12T19:18:02.925+11:00FYI you have to remember that WOW64 was originally...FYI you have to remember that WOW64 was originally designed for IA64 where it has to run a x86 CPU emulator.Yuhong Baohttps://www.blogger.com/profile/14519473280837410246noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-57771997440130887462011-01-28T17:46:43.801+11:002011-01-28T17:46:43.801+11:00Sounds like Microsoft is deliberate shutting out a...Sounds like Microsoft is deliberate shutting out any GC implementations for C / C++ in a desperate and illegal attempt to protect its investments in .NET.<br /><br />This just *screams* antitrust - the governments (EU is our best hope) should take a serious look at this case!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-90144032061074984772011-01-27T22:44:38.962+11:002011-01-27T22:44:38.962+11:00First, congratulations on actually finding this bu...First, congratulations on actually finding this bug. I've first encountered it while trying to make the Open Dylan IDE work on Vista 64 bit. I couldn't locate the source of the problem, suspected a bug in our compiler, and finally gave up. GC in this case was MPS.<br /><br />I'm disappointed that MS won't fix this bug. That completely destroys binary compatibility with just about any 32 bit application that uses garbage collection. Which essentially means any program written in a language that does GC. Including ours.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-39899953394818362832010-12-21T02:31:03.837+11:002010-12-21T02:31:03.837+11:00> So do you mean that Intel is delivering micro...> So do you mean that Intel is delivering microcode patches to the end end users? I don't see this happen broadly. It should be either BIOS update or OS update. <br /><br />I thought Microsoft has something called "Windows Update" for that particular purpose or am I missing something?<br /><br />This blog really sheds a bad light on Microsoft's already bad business practice.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-19114042268530781462010-11-24T19:47:11.530+11:002010-11-24T19:47:11.530+11:00> ... which is not dynamic enough per your inte...> ... which is not dynamic enough per your interpretation.<br /><br />You twisted my words again. I was talking about fixing bugs that don't affect a whole lot of people. You said MSFT won't do that (or would you like to backpaddle on that as well?), I said Intel did and would continue to do so.<br /><br />> You didn't offer however any way to avoid that and don't ruin the business.<br /><br />I don't know how Intel does it, or Google as well with giving away Andriod for free. But, I did provide examples of others who do it better than MSFT. It's up to MSFT as an entity to learn.<br /><br />> Is it possible to make such business profitable?<br /><br />And you know it won't be profitable because...?<br /><br />> It is a plain fact, not my opinion. Commercial OSes _are_ commercial software.<br /><br />DUH! What an intelligent observation. Yes they are commercial software, but let me repeat again, "not /just/ any commercial software". Perhaps you might want to ask someone what that means.<br /><br />This will be my last reply because we /really/ are getting around in circles with you (deliberately or not) replying non-sensibly and twisting my words. I don't see a point of continuing with this discussion.Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-17060321512769356132010-11-24T14:39:03.469+11:002010-11-24T14:39:03.469+11:00> Yes, but that doesn't stop Intel from doi...> Yes, but that doesn't stop Intel from doing it via Microcode patch.<br /><br />So do you mean that Intel is delivering microcode patches to the end end users? I don't see this happen broadly. It should be either BIOS update or OS update. BIOS updates are not done routinely by end users. OS updates are much more frequent but they go though the same triage process as other OS updates, which is not dynamic enough per your interpretation.<br /><br />> Yes, and I thought the discussion was how to improve that?<br /><br />Well, so far what is have said is that you don't like that business reasons dictate that commercial software will have a bunch of bugs in it. You didn't offer however any way to avoid that and don't ruin the business.<br /><br />> I honestly think we'll have to agree to disagree in this case. I see OS (or at least WinAPI and the functionalities it exposes) to be closer to CPU while you kept comparing it to commercial software. We're not talking about .NET framework, ...<br /><br />How are you going to draw the line? For example WinAPI includes tons of high level stuff, really high level. Or why suddenly .NET framework is not considered? It is much closer to CPU-like services than WinAPI.<br /><br />> Again, that's where your opinion differs from mine - OS is not /just/ any commercial software development.<br /><br />It is a plain fact, not my opinion. Commercial OSes _are_ commercial software.<br /><br />Now I'd be interested to hear your opinion how it could be changed to the model you think is right - OS is like a CPU from a business point or view. Is it possible to make such business profitable?Alexey Pakhunovhttp://blog.not-a-kernel-guy.comnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-2886496165145483842010-11-23T19:58:28.142+11:002010-11-23T19:58:28.142+11:00> My point was that fixing a bug in house is ch...> My point was that fixing a bug in house is cheap and easy. Distributing the fix to the end user is hard and expensive.<br /><br />Yes, but that doesn't stop Intel from doing it via Microcode patch.<br /><br />> I have some facts describing how it is to report a bug in Windows.<br /><br />Yes, and I thought the discussion was how to improve that? Which was why Intel was brought into the discussion as an example of how MSFT should learn from?<br /><br />> I thought this was a reasonable discussion.<br /><br />This topic has gone one big circle and yet I see no reasonable discussion taking place. I honestly think we'll have to agree to disagree in this case. I see OS (or at least WinAPI and the functionalities it exposes) to be closer to CPU while you kept comparing it to commercial software. We're not talking about .NET framework, Boost etc. or Photoshop, Internet Explorer, etc. I see WinAPI functions to be no different to the functionalities you get from CPU such as FDIV. You'll find each have their own complexities and cost in distributing a fix to end users. Like I said, it's even more costly for Intel.<br /><br />> I don't know. I wasn't skilled enough at the time to go all the way through.<br /><br />Point me to the errata and I'll take a look for ya.<br /><br />> BTW, what if I say that thread hijacking does not actually work on native( x86, amd64 or ia64) either? In some scenarios. I don't know exactly how you use it.<br /><br />I'm not exactly hijacking a thread (hijacking was your word) - I don't do SetThreadContext - only GetThreadContext, the same way Debuggers work (unless you meant debuggers shouldn't rely on GetThreadContext to get the current stack pointer of a thread either).<br /><br />> Now it seems that there is no way one can achieve this using the current model of commercial software development.<br /><br />Again, that's where your opinion differs from mine - OS is not /just/ any commercial software development. Intel could've simply said the same about Pentium FDIV bug.Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-5276240099810647312010-11-23T04:19:57.014+11:002010-11-23T04:19:57.014+11:00> That statement was in reply to your assertion...> That statement was in reply to your assertion that Intel's not dynamic.<br /><br />Well, then you should say that Microsoft is also dynamic. We fix bugs in the very core of the OS and sometimes such fixes are based on someones post in some blog. :-)<br /><br />My point was that fixing a bug in house is cheap and easy. Distributing the fix to the end user is hard and expensive. This is true for both Intel and Microsoft and it is true measure of dynamism. <br /><br />> Huh? How's that even remotely similar? Can I talk to someone without paying?<br /><br />You can actually do quite a few things without paying. Just like you can do them at Intel's counterpart. <br /><br />I understand you fixation on the "payment question", but I believe that the point I was trying to draw your attention to is not very relevant to this. Even if it is so frustrating.<br /><br />> So, how's that proof that end users can't report a CPU bug?<br /><br />Oh, come on! Intel does not need you defending it. I'm not trying to prove that Intel is bad or anything like that. <br /><br />I'm honestly saying that I have some facts describing how it is to report a bug in Windows. I'm also saying that I don't have same kind of facts about anyone reporting a bug in Intel's CPU. That is it. <br /><br />> If the goal is to stick your head in the sand, you've achieved it.<br /><br />I thought this was a reasonable discussion. Please don't turn it into a "There can be only one" type of discussion.<br /><br />> And for the retail version, did Intel /not/ fix the bug via microcode patch (or at least put out an errata to allow for workarounds)?<br /><br />I don't know. I wasn't skilled enough at the time to go all the way through.<br /><br />> Perhaps that's not a good idea. The deeper I look at the rationale of risk vs rewards, the more I disagree it's the right model for an OS.<br /><br />No, why? A negative answer "no that is not the right model" is also a good answer if it is well thought through.<br /><br />> An OS is more similar to a CPU than a software library / application.<br /><br />You've got a point but you are talking about different angle of the problem. So it is not surprising that you end up with a different answer.<br /><br />I agree that it would be really great that OSes (and other software too!) was as bug free as processors are. Now it seems that there is no way one can achieve this using the current model of commercial software development. But at the same time writing virtually bug free software is not a self sustainable business. It work out only in aerospace and medical industries and only because of harder safety requirements.Alexey Pakhunovhttp://blog.not-a-kernel-guy.comnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-34453499861780120952010-11-22T18:46:11.045+11:002010-11-22T18:46:11.045+11:00> Have TBB team redistributed an updated versio...> Have TBB team redistributed an updated version of TBB to the end users? ...<br /><br />That statement was in reply to your assertion that Intel's not dynamic.<br /><br />> You will not believe it but Microsoft also has support page that is not much different from Intel's one: http://support.microsoft.com/<br /><br />Huh? How's that even remotely similar? Can I talk to someone without paying?<br /><br />> Last time I needed to report a bug I could use a private channel.<br /><br />So, how's that proof that end users can't report a CPU bug? With MSFT, end users have to /PAY/ to report a Windows bug via support.<br /><br />If the goal is to stick your head in the sand, you've achieved it.<br /><br />> I've encountered three bugs for far. Two in a beta version of a processor and one - in a retail version.<br /><br />Beta. Let's see, how many bugs did beta users report against Win7 beta?<br /><br />And for the retail version, did Intel /not/ fix the bug via microcode patch (or at least put out an errata to allow for workarounds)?<br /><br />> I just would like you to take a deeper look at the problem.<br /><br />Perhaps that's not a good idea. The deeper I look at the rationale of risk vs rewards, the more I disagree it's the right model for an OS.<br /><br />An OS is more similar to a CPU than a software library / application. You can't swap out a buggy part of the OS for a working one just like you can for a library.<br /><br />In this case, this OS bug is a *show-stopper* for us.Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-86876012821003981502010-11-21T07:41:04.902+11:002010-11-21T07:41:04.902+11:00> TBB team responded to my queries promptly and...> TBB team responded to my queries promptly and some changes were made to the way TBBMalloc allocates/deallocates memory. Could it have affected existing applications? Most certainly.<br /><br />Have TBB team redistributed an updated version of TBB to the end users? Or have they made anyone using TBB to recompile their applications and redistribute them to the end users?<br /><br />If not, than why do you care that bugs are fixed primarily in next versions of Windows, not in the released ones?<br /><br />> where's the MSFT equivalent?<br /><br />You will not believe it but Microsoft also has support page that is not much different from Intel's one: http://support.microsoft.com/<br /><br />It does not tell me much that Intel has a well structured support page and some support people in staff. The question was "is it possible for an end user to report a bug in a CPU?". I sort of know the answer to the question "is it possible for an end user to report a bug in Windows?" but only because other people shared their experience. It is possible but bumpy. Unfortunately I don't known anyone having such experience with Intel. Last time I needed to report a bug I could use a private channel.<br /><br />> If you have a bug against the CPU you'd like to report (which I doubt in your lifetime that you would come across even one)<br /><br />I've encountered three bugs for far. Two in a beta version of a processor and one - in a retail version. Never say never. :-)<br /><br />> You come across to me as someone who believes MSFT is a corp which has one of the best business practices<br /><br />I didn't say that. I've said that there are business reasons to treat bug as Microsoft is doing.<br /><br />> Is it so hard to accept that there're things MSFT could've done much better?<br /><br />Surely there is a number of ways things Microsoft could have done better. Much better. I'm not saying that that way it is now is perfect. I just would like you to take a deeper look at the problem.Alexey Pakhunovhttp://blog.not-a-kernel-guy.comnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-83996642674573330402010-11-20T12:13:23.836+11:002010-11-20T12:13:23.836+11:00Last I checked, even their TBB team responded to m...Last I checked, even their TBB team responded to my queries promptly and some changes were made to the way TBBMalloc allocates/deallocates memory. Could it have affected existing applications? Most certainly. Mind you, that's *not* even Intel's core business.<br /><br />I'm surprised you even asked - have you done a search on "Contact Intel Support"?<br /><br />If you have a bug against the CPU you'd like to report (which I doubt in your lifetime that you would come across even one), here's how: http://www.intel.com/support/feedback.htm?group=processor<br /><br />And it's really simple to get to the page as well. The contact support page has all Intel's product groups well laid out in one page - where's the MSFT equivalent?<br /><br />You come across to me as someone who believes MSFT is a corp which has one of the best business practices out there and all other giant sized companies must be around the same standard too. Is it so hard to accept that there're things MSFT could've done much better?Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-63195625472131898072010-11-20T12:05:25.172+11:002010-11-20T12:05:25.172+11:00> Security bugs are considered the most riskie...> Security bugs are considered the most riskier ones (remember years 2000, 2001?) from business point of view.<br /><br />Oops. Not risky ones, rewarding ones.<br /><br />From the risk/reward evaluation security changes are the most _rewarding_. The reward is that by fixing it eliminate security threat which otherwise can turn into a large business expense.Alexey Pakhunovhttp://blog.not-a-kernel-guy.comnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-59993559916039809162010-11-20T03:33:14.592+11:002010-11-20T03:33:14.592+11:00> Did you read my reply about DEP and Firewall?...> Did you read my reply about DEP and Firewall? Did you have the stats of the number of apps DEP broke?<br /><br />1. Some service packs included features. <br />2. Some changes we made broke many applications. <br /><br />So what? It does not change my statement about risk/reward evaluation of changes we do. DEP & Firewall changes were made to improve security of the system. Security bugs are considered the most riskier ones (remember years 2000, 2001?) from business point of view. Patches distributed via Windows Update almost entirely dedicated to security problems.<br /><br />> I get the impression that the core values of MSFT is very different from that of Intel.<br /><br />I don't have a well grounded opinion on this. I worked with Intel on a couple of _software_ projects. I didn't get impression of dynamic and proactive company. <br /><br />BTW, I'm just curious, is there a web form or e-mail address or anything else open to general public specifically created to report bugs in Intel processors? <br /><br />> MSFT is definitely favouring big corps over small firms.<br /><br />I've heard arguments both supporting this statement and proving it wrong. I'm not sure whether the balance is met or not. <br /><br />> Last time I heard, Microsoft had $60 billion in the bank. Surely that's enough resources to fix a few bugs?<br /><br />I'm not qualified to make decisions how to spend this kind of money. So I don't know if it makes sense to fix more bugs from business point of view.<br /><br />> I would imagine it requires some sort of thread hijacking as well for performance.<br /><br />I don't know enough about this. Thread hijacking is not the only technique. You can insert control points into generated code.Alexey Pakhunovhttp://blog.not-a-kernel-guy.comnoreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-53943225630469969742010-11-20T01:20:49.007+11:002010-11-20T01:20:49.007+11:00How does .NET's GC get hold of its current sta...How does .NET's GC get hold of its current stack pointer of a specific thread when the GC runs?<br /><br />I would imagine it requires some sort of thread hijacking as well for performance. Is it not affected by this bug then?Zach Sawhttps://www.blogger.com/profile/02019604928253273845noreply@blogger.comtag:blogger.com,1999:blog-9977539741480046.post-8860470053569162042010-11-19T23:54:15.787+11:002010-11-19T23:54:15.787+11:00Last time I heard, Microsoft had $60 billion in th...Last time I heard, Microsoft had $60 billion in the bank. Surely that's enough resources to fix a few bugs?Anonymousnoreply@blogger.com