We got an interesting application crash yesterday with a confusing message similar to this:
Fault bucket 42424242, type 1
Event Name: APPCRASH
Response: None
Cab Id: 0
Problem signature:
P1: MyApp.exe
P2: 1.42.42.42
P3: 598773cf
P4: StackHash_ac62
P5: 0.0.0.0
P6: 00000000
P7: c0000007
P8: 00000000
P9:
P10:
We spent some time wondering if our crypto libraries were the problem (we just made some changes recently), but concluded that was unlikely. So what the heck is the “StackHash” module? Did our trashed stack cause the kernel to think we were a different module? Nope.
The answer is that the Windows executive couldn’t identify the module we were in when the application crashed (it uses the instruction pointer to determine what code was executing). In this case, the kernel simply takes a hash of the stack so at least we might be able to identify if we’ve seen this exact crash before. Here’s the answer summarized by an engineer from Microsoft:
In the OS when I try to get a faulting module name it is possible that there is no module laoded (sic) at that address. For example in this case the EIP was zero. So in those cases where a module is not loaded and it is not also in the unloaded module list, I take a stack hash of the stack so that we can identify this crash from other crashes where also the module is not known.
The SDTimes has an article up about a new operating system Microsoft is working on called “Midori”. It is based on their “Singularity” OS, with everything being written in managed code then natively compiled. Rumor has it that this is the follow-on to the Windows platform… we’ll see if it ever materializes commercially. SDTimes bases the article on some internal documents they got access to, which may be why we haven’t seen this level of detail before (see the entry in Wikipedia). From the article:
According to the documentation, Midori will be built with an asynchronous-only architecture that is built for task concurrency and parallel use of local and distributed resources, with a distributed component-based and data-driven application model, and dynamic management of power and other resources.
The Midori documents foresee applications running across a multitude of topologies, ranging from client-server and multi-tier deployments to peer-to-peer at the edge, and in the cloud data center. Those topologies form a heterogeneous mesh where capabilities can exist at separate places.
In order to efficiently distribute applications across nodes, Midori will introduce a higher-level application model that abstracts the details of physical machines and processors. The model will be consistent for both the distributed and local concurrency layers, and it is internally known as Asynchronous Promise Architecture.
…operating system services, such as storage, would either be provided to the applications by the OS or be discovered across a trusted distributed environment.
Here are some links to 3 great articles by Mark Russinovich about new features in the Windows Vista kernel (Ntoskrnl.exe).
Inside the Windows Vista Kernel: Part 1
