# Understanding User and Kernel Mode

**URL:** <https://discourse.codinghorror.com/t/understanding-user-and-kernel-mode/405>\
**Category:** blog\
**Created:** [January 3, 2008, 12:00am UTC](https://discourse.codinghorror.com/t/understanding-user-and-kernel-mode/405 "2008-01-03T00:00:00Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![codinghorror](https://discourse-cdn.codinghorror.com/user_avatar/discourse.codinghorror.com/codinghorror/32/36371_2.png) [@codinghorror](https://discourse.codinghorror.com/u/codinghorror)\
**Post date:** [January 4, 2008, 12:00am UTC](https://discourse.codinghorror.com/t/understanding-user-and-kernel-mode/405/6 "2008-01-04T00:00:00Z")

</div>

For the many “exceptions don’t cause a transition to kernel mode” commenters, I refer you to Chris Brumme’s post, already linked by Mike Dimmick (thanks Mike)

# [http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx](http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx)

Consider some of the things that happen when you throw an exception:

- Grab a stack trace by interpreting metadata emitted by the compiler to guide our stack unwind.
- Run through a chain of handlers up the stack, calling each handler twice.
- Compensate for mismatches between SEH, C++ and managed exceptions.
- Allocate a managed Exception instance and run its constructor. Most likely, this involves looking up resources for the various error messages.
- **Probably take a trip through the OS kernel. Often take a hardware exception.**
- Notify any attached debuggers, profilers, vectored exception handlers and other interested parties.  
==

Operative words being “probably take a trip through the OS kernel.”

---

_[View the full topic](https://discourse.codinghorror.com/t/understanding-user-and-kernel-mode/405)._