Patent Description:
In an out-of-process inspection model, the debugger cannot corrupt the state of the debuggee. The developer sees a raw view of the debuggee state, which tends to be at a lower level than the abstraction the API designer intended. This is because the debugger can only obtain the backing values of a property if they are accessible in debuggee memory. For instance, if a property's value is calculated, the debugger can only show the raw variables used in the calculation.

Properties with values that depend on state outside the debuggee's memory, such as state shared with other processes (either in memory or on a storage media), state from some other connected device, removable storage, etc., cannot be read in this manner. Other state-dependent values that cannot be read in this way are states in the operating system kernel or cross-machine implemented states. The out-of-process model requires the developer to reverse engineer the implementation of the API abstraction from the values available as raw variables, which can be difficult, confusing, or impossible to do.

For the in-process or func-eval model, the developer sees the exact view of the abstraction the API designer intended. No mapping from implementation to public view is necessary. However, in a func-eval model, any side effects for the implementation of the property will affect debuggee state, which may lead to developer confusion and incorrect debuggee behavior. The debuggee may not be in a state where code can be executed, such as highly stressed processes that are near out-of-memory situations or threads within the process that have entered the kernel. In this state, debugger inspection is impossible. Executing a function-evaluation can lead to debuggee deadlock or corruption. Specifically if the implementation of a property depends other threads executing. For instance, if a property tries to take a lock held by another thread, that property cannot execute unless the thread that holds the lock releases it, leading to deadlock.

Furthermore, in the proxy/stub model used by some distributed environments, the call may require multiple threads to execute in order to enable another thread to "pump" or handle an incoming call from another thread that is doing a func-eval. Allowing the other threads in the process to run (i.e. "slipping the threads") is something the debugger generally cannot allow because the actual execution point for every thread would change on each func-eval. Such cross-context calls can lead to un-recoverable corruption of the debuggee if they do not complete correctly.

<CIT> relates to simulating operations through out-of-process execution. When a diagnostic operation is to be performed for a target execution context, a separate execution context is created based on the same executable code used to create the target execution context. An execution boundary separates the target execution context and the separate execution context such that execution in the separate execution context does not influence the behavior of the target execution context. State data from the target execution context is marshaled and transferred to the separate execution context. The separate execution context reconstitutes the state data and uses the state data to perform the diagnostic operation.

<CIT> describes that snapshots of a debuggee's state during a debug session are captured. A debugger UI, which may comprise one or more graphical views such as tabs or frames, sits on top of a set of classes that represent elements of a debuggee and which are instantiated to a set of objects for a particular debuggee during a debug session, collectively called the Model. The Model includes a complete representation of the state and debug information of the debuggee. When state and debug information of the debuggee is needed for display in the debugger Ul, the debugger UI can obtain this information by calling methods on objects in the Model that correspond to that debuggee state and debug information. For example, the Model may contain objects which represent the debuggee's threads, register values, storage contents, call stack entries, etc..

It is the object of the present invention to provide improved in-process debugging of a target process.

Using lightweight process snapshot support in the operating system, the debugger creates a copy of the debuggee target process and performs func-eval inspection against the copy. This leaves most debuggee state in the target process intact since any changes made by the func-eval are local to the snapshot copy. Any catastrophic failures during func-eval, such as deadlocking the debuggee process, have minimal impact because the original process remains untouched and the snapshot can simply be thrown away and recreated. Debugger operations that would be too destructive to the debuggee process can be performed on the process snapshot without threatening the real process. For example, slipping all threads during a func-eval is one such scenario.

Slipping all threads is required, for example, in distributed environments where calls between objects may traverse thread boundaries, such as Single-Threaded Apartments in COM. Performing a normal func-eval on such an object will deadlock - and possibly corrupt - the debuggee process because the target thread will not be running. However, allowing all threads to run ("slip") means that the state of the process may be drastically changed after the func-eval is complete. Furthermore, important debugger events such as breakpoints or exceptions, which occur on slipping threads, are likely to be ignored since the debugger will not want to enter break state at that point. Process snapshots allow the debugger to perform a func-eval while slipping all threads and not lose the actual state of the original debuggee process.

The debugger uses lightweight process snapshots to isolate side-effects of func-evals. The debugger may also create new lightweight process snapshots of the target debuggee process when a func-eval side effect no longer reflects the target process or a snapshot becomes so corrupt it can no longer be used.

In one embodiment, a debugger uses a lightweight process snapshot of a target debuggee process and performs func-evals against that snapshot. The debugger uses lightweight process snapshots of the target debuggee process for the func-eval. The debugger is not likely to slip the threads unless necessary, such as if the func-eval did not complete soon enough and had to be aborted in which case slipping may be tried. The debugger may allow all threads in the process snapshot to execute (slip) during a func-eval in order to avoid deadlocking the debuggee process when inter-thread dependencies are encountered.

The debugger may also use a lightweight machine snapshot of the real debuggee machine and perform func-evals against that machine snapshot to further isolate kernel side effects and other more global side effects, such as file writes. The debugger may use lightweight machine snapshots of a debuggee machine and allow all threads in a target process to execute (slip) during a func-eval in order to avoid deadlocking the debuggee machine when inter-thread dependencies are encountered. The debugger may use the lightweight machine snapshots to isolate side-effects of func-evals. The debugger creates new lightweight machine snapshots when a func-eval side effect no longer reflects the original process or a snapshot becomes so corrupt it can no longer be used.

To further clarify the above and other advantages and features of embodiments of the present invention, a more particular description of embodiments of the present invention will be rendered by reference to the appended drawings. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

Function evaluation (func-eval) is the preferred mechanism for modem debuggers to inspect debuggee state. It allows the original abstraction intended by the API author to exactly match the state the developer sees in the debugger. However, as described above, func-eval has several drawbacks including side-effects, deadlocks, and debuggee corruption.

A debugging and diagnostics system allows users to take lightweight process snapshots of live debuggee processes so the users may analyze those snapshots at a later time. The debugging and memory diagnostics system may be used in production scenarios because it minimizes disruption to the production system while still allowing the user to capture snapshots of process states. The lightweight process snapshots enable inspection of a process's callstacks, variable values, memory, module list, thread list and the like while allowing the original process to continue executing.

The snapshot mechanism allows diagnostic tools to compare an original process to one or more process snapshots or to compare any of a series of process snapshots to each other. The snapshot mechanism further allows users to inspect a snapshot of process memory while allowing the original process to continue running with minimal impact.

The term lightweight process snapshot or "snapshot" as used herein refers to a copy of a process that can be created efficiently without needing to create a full trace of the process's execution or memory. In a typical embodiment, an operating system implements the snapshot mechanism on top of a virtual memory model and uses shared memory pages and copy-on-write techniques to avoid the need to create a complete copy of the process. Copy-on-write allows the operating system to map the actual pages of the entire address space of the original process into a second process snapshot quickly. To provide a higher level of isolation, the process snapshot may be created using a virtual machine such as Microsoft Corporation's Drawbridge picoprocess, which is a lightweight, secure isolation container that may run the lightweight process snapshot.

Using lightweight process snapshots or lightweight machine snapshots, as described herein, a debugger may avoid these problems by running full func-evals against the process snapshot of the real debuggee process or against a virtual machine based snapshot of the entire machine the debuggee is running on. These snapshots may be discarded and/or recreated whenever necessary.

Embodiments create lightweight process snapshots or create lightweight machine snapshots to enable function evaluation in a debugger inspection without risk of corrupting or deadlocking the debuggee process and while minimizing the side-effects of doing inspection. A lightweight process snapshot, also referred to herein as a process snapshot, is a copy of the process that is created efficiently without needing to create a full trace of the process's execution or memory. Typically, an operating system implements a snapshot mechanism on top of its virtual memory model and uses shared memory pages and copy-on-write techniques to avoid creating a complete copy of the process. Instead, copy-on-write allows the operating system to map the actual pages of the entire address space of the original process into a second process snapshot quickly. After the snapshot is created, any memory writes to either process cause a copy of that corresponding memory page to be created for the process doing the writing. Thus, side-effect isolation is achieved for memory writes.

A debugger using the func-eval based inspection model against lightweight process snapshots applies the following algorithm:.

First, when a debugger enters break mode, the debugger asks the operating system to create a new lightweight snapshot of the original process. This snapshot must accurately reflect the original process, including mapping the debuggee process memory via copy-on-write, duplication of threads within the process, duplication of any handles within the process, and loading of same modules in the process. The debugger must be able to execute code within the process snapshot in order to perform a func-eval.

Second, when the debugger needs to perform a func-eval, it does so within the lightweight process snapshot process, not within the original process. This provides the same results as if the func-eval was run against the original because the snapshot is a clone of the original process and, therefore, doing a func-eval within the process snapshot will be identical to doing a func-eval within the original debuggee process.

It is noted that some side-effects may not be isolated using this model depending on the level of duplication the operating system supports. For example, side effects to external entities, such as file writes during a func-eval, will actually occur. Furthermore, if the operating system is not capable of duplicating the full process, side-effects to anything that is not duplicated, such as shared kernel objects, could actually affect the original process.

Third, when performing a func-eval within the snapshot process, the debugger may choose to slip all threads in the real debuggee process. That allows all threads in the real debuggee process to execute. This reduces the likelihood of deadlocking the debuggee process if it were to make calls across distributed environments such as COM apartment boundaries or to allow locks to be released that may be held by other threads. If the debugger does an evaluation that allows for threads to slip, the debugger will need to create a new snapshot of the original process after the evaluation is completes. This is necessary because the state of the process snapshot will have changed significantly after the evaluation and may no longer be an accurate representation of the current real debuggee process.

Fourth, when a func-eval in the process snapshot goes wrong - e.g., it times out because of a deadlocked func-eval, or there are obvious side effects from previous evaluations that the developer wishes to undo - a debugger may simply delete the old snapshot and create a new one. The new process snapshot is once again a duplicate of the original process.

In some cases, the debugger will know to create a new process snapshot automatically. For example, the debugger will always need to create a new process snapshot when it enters break mode after being in run mode. This is needed because the debuggee state will likely have changed drastically between break states. However, there are times when the user may need to force the creation of a new snapshot. This may be enabled through the debugger user interface.

<FIG> illustrates historical debugging with lightweight process snapshots. A debugger process <NUM> is used to debug the debuggee process <NUM>. The debugger process <NUM> has a user interface that allows the user to analyze components of the debuggee process. For example, the user interface may provide windows showing callstack <NUM>, modules <NUM>, threads <NUM>, and variable inspection <NUM>. The debuggee process <NUM> comprises, for example, threads <NUM>, modules <NUM>, and a virtual memory page table <NUM>. Virtual memory <NUM> points to physical memory pages <NUM> that are managed by the operating system's virtual memory manager <NUM>.

During the debug session lightweight process snapshots <NUM> and <NUM> are created. These are snapshots of the debuggee process <NUM> taken at a specific time. The snapshots <NUM>, <NUM> may be manually initiated by the user, or the debugger <NUM> may automatically generate the snapshots <NUM>, <NUM> when a particular event or trigger is observed or at certain intervals.

Snapshot <NUM> comprises a thread table <NUM> and modules table <NUM>, which are copies of debugger <NUM>'s internal tables at the time (T1) that snapshot <NUM> was created. Virtual memory page table <NUM> points to the physical memory pages <NUM> that were in use at time T1 when snapshot <NUM> was created. Initially, virtual memory <NUM> and virtual memory <NUM> will be identical; however, as debuggee process continues to run virtual memory <NUM> will change as its page table points to updated memory locations <NUM>.

Similarly, at another time (T2), process snapshot <NUM> is created in response to a user selection or the occurrence of an event or trigger observed by the debugger process <NUM>. Snapshot <NUM> includes copies of thread table <NUM> and modules table <NUM> at time T2 when the snapshot was created along with a copy of the then-current virtual memory page table <NUM>.

Snapshots <NUM>, <NUM> allow the debugger process <NUM> or the user to look back at what debuggee process <NUM> looked like at the time (T1, T2) when snapshots <NUM>, <NUM> were created even though debuggee process <NUM> has changed in the meantime. Also, the debugger process can compare states between and among debuggee process <NUM> and/or process snapshots <NUM>, <NUM> to generate differentials between the different process states at different times so that the user can see what part of the process has changed and how.

In other embodiments, a snapshot <NUM> may be created and the original debuggee process <NUM> may be allowed to run without interference. Tests may then be run against process snapshot <NUM> to observe how the process is affected. If process snapshot <NUM> fails or has other problems due to the tests, then those problems will not affect the real running process <NUM>.

<FIG> illustrates a lightweight process snapshot according to one embodiment. Original process <NUM> includes a page table <NUM> that points to data stored in physical memory <NUM>. For example, process <NUM> may store a variable X in page table entry <NUM>, which points to a physical memory location <NUM> where the value for variable X is actually stored.

When process snapshot <NUM> is created from original process <NUM>, original page table <NUM> is copied as snapshot page table <NUM>. The content of snapshot page table <NUM> is the same as the content of original page table <NUM> as it existed at the time the snapshot was created. For example, in process snapshot <NUM>, variable X points to an entry <NUM> in snapshot page table <NUM>, which - like original page table <NUM> - points to physical memory location <NUM> where the value for variable X is stored.

Original process <NUM> may continue to run after the snapshot is created. The original process may generate a new value for variable X, which is again stored in entry <NUM> of original page table <NUM>. However, the new value for variable X is stored in physical memory <NUM> in a new location <NUM>. Accordingly, original page table <NUM> is updated to point to physical memory location <NUM>, but snapshot page table <NUM> maintains its snapshot state and points to memory location <NUM> where the original value of variable X still resides.

The snapshot mechanism allows for a less destructive debug inspection. Typically when in break mode while debugging a process, the debuggee process is halted by the operating system. This means code within the debuggee process does not execute. This is ideal for inspecting the debuggee state because that state cannot change while the process is halted. However, in some scenarios, halting the process can lead to dead-locks or other system instability. For example, when the debuggee process is shared among other processes, the other processes may attempt to communicate with the shared debuggee process while in break mode. This can lead to delays in other processes in the best case and deadlocks, process corruption, and instability in the worst case. The lightweight snapshot model enables debugging in such scenarios by allowing the debugger to inspect a lightweight process snapshot of the shared process rather than the real process. The real process is allowed to continue execution during this inspection.

<FIG> is a flowchart illustrating a method for performing function evaluations against lightweight process snapshots according to one embodiment. In step <NUM>, the debugger enters break mode while debugging a debuggee process. The debugger requests the operating system to create a process snapshot of the debuggee process. In step <NUM>, the debugger performs a function evaluation against the process snapshot. The debugger may perform multiple function evaluations against the process by cycling back to step <NUM>. If the debugger identifies problems in the function evaluation it moves to step <NUM> and discards the process snapshot.

In step <NUM>, the debugger requests the operating system to create a new process snapshot of the debuggee process. The process returns to step <NUM> to perform additional function evaluations against the new process snapshot. Then the debugger may again perform a functional evaluation of the new process snapshot by returning to step <NUM>. Alternatively, in step <NUM>, the debugger may slip the threads in the debuggee process while performing the functional evaluation of the new process snapshot. If the function evaluation fails or problems such as a deadlock are encountered, then the process returns to step <NUM> to discard the deadlocked process snapshot and to step <NUM> to create another new process snapshot.

It will be understood that steps <NUM>-<NUM> of the process illustrated in <FIG> may be executed simultaneously and/or sequentially. It will be further understood that each step may be performed in any order and may be performed once or repetitiously.

<FIG> illustrates a debugger performing a function evaluation against a lightweight process snapshot while allowing the real debuggee process to continue running according to one embodiment. A debugger process <NUM> is used to debug the debuggee process <NUM>. The debugger process <NUM> has a user interface <NUM> and debugger engine <NUM> that allow the user to interact with and analyze components of the debuggee process. For example, the user interface may provide windows showing callstacks, modules, threads, and variable values. The debuggee process <NUM> comprises, for example, threads <NUM>, modules <NUM>, and a virtual memory page table <NUM>. Virtual memory <NUM> points to physical memory pages <NUM> that are managed by the operating system's virtual memory manager <NUM>.

Debugger process <NUM> controls the execution of debuggee process <NUM> and may suspend the process or allow the process to run. When the user wants to perform a function evaluation on the debuggee process, debugger process <NUM> requests the operating system to create a lightweight process snapshot <NUM> of debuggee process <NUM>. Snapshot <NUM> comprises a thread table <NUM> and modules table <NUM>, which are copies of the thread and module lists on debuggee process <NUM> when snapshot <NUM> was created. Virtual memory page table <NUM> points to the physical memory pages <NUM> in use when snapshot <NUM> is created. Initially, virtual memory <NUM> and virtual memory <NUM> will be identical.

The debugger process <NUM> then performs the function evaluation against process snapshot <NUM> while slipping the threads on debuggee process <NUM>. If process snapshot <NUM> fails or has other problems due to the function evaluation, then those problems will not affect the real debuggee process <NUM>. If problems occur, debugger process <NUM> can discard process snapshot <NUM> and request the operating system to create a new process snapshot.

In the case where the operating system supports creating, booting, and restoring virtual machines, the debugger may generate a new virtual machine that contains a complete copy of the machine that is running the debuggee process. The debugger can then perform the func-eval against a process snapshot that is running on the virtual machine. This will allow for a fully isolated external state, such as kernel handles, and file writes. The virtual machine may be created, for example, using Microsoft Corporation's Drawbridge picoprocess to create a lightweight virtual machine in which the operating system implementation resides within the debuggee process, which allows the kernel state to be isolated.

A debugger may use virtual machine technology to perform the func-eval against an entire copy of the machine that is running the debuggee process instead of just against a process snapshot. This enables isolating kernel mode side-effects as well as external side effects, such as file writes, that would be impossible to isolate using only a process snapshot. This model is referred to herein as a "machine snapshot. " This model requires an extremely fast virtual machine technology that supports creating, booting, and rolling back a virtual machine very quickly. One such emerging technology is Microsoft Corporation's Drawbridge virtual machine model.

As used herein, the lightweight machine snapshot encompasses a broad range of copies of the host machine and debuggee process requiring varying amounts of isolation and host machine data. In one embodiment, the lightweight machine snapshot is a full snapshot or copy of the debuggee host machine. In other implementations, the machine snapshot may be a copy of the debuggee process and most of the kernel, but nothing else on the system. Other implementations may use: just a snapshot of a single debuggee process, a process snapshot with kernel state, everything on the debuggee machine, or multiple host machines.

<FIG> illustrates a debugger performing a function evaluation against a lightweight machine snapshot while allowing the real debuggee process to continue running on the host machine according to one embodiment. Host machine <NUM> is running debugger process <NUM>, which is used to debug the debuggee process <NUM> also running on host machine <NUM>. A user interface and debugger engine on debugger process <NUM> allow the user to interact with and analyze components of the debuggee process <NUM>. Virtual memory in debuggee process <NUM> points to physical memory pages <NUM> that are managed by the operating system's virtual memory manager <NUM>.

Debugger process <NUM> controls the execution of debuggee process <NUM> and may suspend the process or allow the process to run. When the user wants to perform a function evaluation on the debuggee process, debugger process <NUM> requests the operating system to create a virtual machine snapshot <NUM>.

Virtual machine snapshot <NUM> is complete copy of the host machine <NUM> that is running debuggee process <NUM>. Virtual machine snapshot <NUM> includes a process snapshot <NUM>, which is a complete copy of debuggee process <NUM> at the time the virtual machine snapshot was created. Process snapshot <NUM> comprises thread table modules tables that are copies of the thread and module lists on debuggee process <NUM> when machine snapshot <NUM> was created. Virtual memory page table <NUM> does not point to the physical memory pages <NUM> in the host machine memory, but instead points to memory pages <NUM> on the virtual machine. The virtual machine snapshot also includes a kernel state <NUM> and files <NUM> copied from the host machine <NUM>.

The debugger process <NUM> performs the function evaluation against virtual machine snapshot <NUM> while slipping the threads on debuggee process <NUM>. If machine snapshot <NUM> fails or has other problems due to the function evaluation, then those problems will not affect the real debuggee process <NUM> or any other process running on host machine <NUM>. Any kernel mode side-effects or external side effects, such as file writes, are isolated to virtual machine snapshot <NUM>. If problems occur, debugger process <NUM> can discard machine snapshot <NUM> and request the operating system to create a new machine snapshot.

<FIG> illustrates an in-process debugging session using lightweight process snapshots. Debugger process <NUM> initiates a debugging session (<NUM>) with debuggee process <NUM>. Debugger <NUM> requests (<NUM>) operating system <NUM> to create a first process snapshot <NUM> of debuggee <NUM>.

Debugger <NUM> performs func-eval (<NUM>) on process snapshot <NUM>, which executes the function (<NUM>) and returns results (<NUM>).

Debugger <NUM> then performs a corrupting func-eval (<NUM>) on process snapshot <NUM>, which executes the function (<NUM>) and returns results (<NUM>). Process snapshot <NUM> is corrupted after executing the function (<NUM>). So debugger <NUM> discards process snapshot <NUM> and requests (<NUM>) operating system <NUM> to create a second process snapshot <NUM>.

After performing the func-evals <NUM> and <NUM> without slipping, debugger <NUM> creates second process snapshot <NUM> after first process snapshot <NUM> deadlocks. Debugger <NUM> then performs thread slipping func-eval (<NUM>) on process snapshot <NUM>, which executes the function (<NUM>) while all threads are slipping in debuggee process <NUM>. Snapshot process <NUM> returns results (<NUM>). Because all threads in debuggee process <NUM> were slipping while snapshot process <NUM> executed the function, snapshot process <NUM> is no longer an accurate copy of debuggee process <NUM>. Accordingly, debugger <NUM> discards process snapshot <NUM> and requests (<NUM>) operating system <NUM> to create a third process snapshot <NUM>.

Debugger <NUM> then performs func-eval (<NUM>) on process snapshot <NUM>, which executes the function (<NUM>) and returns results (<NUM>). The user may direct (<NUM>) the debugger <NUM> to discard the process snapshot <NUM> and create a new snapshot. Debugger <NUM> then discards process snapshot <NUM> and requests (<NUM>) operating system <NUM> to create a fourth process snapshot <NUM>.

Debugger <NUM> performs thread slipping func-eval (<NUM>) on process snapshot <NUM>, which executes the function (<NUM>) while all threads are slipping in debuggee process <NUM>. Snapshot process <NUM> returns results (<NUM>).

The debugger <NUM> ends debugging (<NUM>) when func-eval is complete.

If operating system <NUM> supports creation of virtual machine snapshots, then process snapshots <NUM>, <NUM>, <NUM>, and <NUM> may be replaced with lightweight machine snapshots to further protect and isolate debuggee <NUM>.

<FIG> illustrates an example of a suitable computing and networking environment <NUM> on which the examples of <FIG> may be implemented for in-process debugging using lightweight process snapshots. The computing system environment <NUM> is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.

With reference to <FIG>, an exemplary system for implementing various aspects of the invention may include a general purpose computing device in the form of a computer <NUM>. Components may include, but are not limited to, various hardware components, such as processing unit <NUM>, data storage <NUM>, such as a system memory, and system bus <NUM> that couples various system components including the data storage <NUM> to the processing unit <NUM>. The system bus <NUM> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

The computer <NUM> typically includes a variety of computer-readable media <NUM>. Computer-readable media <NUM> may be any available media that can be accessed by the computer <NUM> and includes both volatile and nonvolatile media, and removable and non-removable media, but excludes propagated signals. By way of example, and not limitation, computer-readable media <NUM> may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer <NUM>. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above may also be included within the scope of computer-readable media. Computer-readable media may be embodied as a computer program product, such as software stored on computer storage media.

The data storage or system memory <NUM> includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer <NUM>, such as during start-up, is typically stored in ROM. RAM typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit <NUM>. By way of example, and not limitation, data storage <NUM> holds an operating system, application programs, and other program modules and program data.

Data storage <NUM> may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, data storage <NUM> may be a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and an optical disk drive that reads from or writes to a removable, nonvolatile optical disk such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The drives and their associated computer storage media, described above and illustrated in <FIG>, provide storage of computer-readable instructions, data structures, program modules and other data for the computer <NUM>.

A user may enter commands and information through a user interface <NUM> or other input devices such as a tablet, electronic digitizer, a microphone, keyboard, and/or pointing device, commonly referred to as mouse, trackball or touch pad. Other input devices may include a joystick, game pad, satellite dish, scanner, or the like. Additionally, voice inputs, gesture inputs using hands or fingers, or other natural user interface (NUI) may also be used with the appropriate input devices, such as a microphone, camera, tablet, touch pad, glove, or other sensor. These and other input devices are often connected to the processing unit <NUM> through a user input interface <NUM> that is coupled to the system bus <NUM>, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor <NUM> or other type of display device is also connected to the system bus <NUM> via an interface, such as a video interface. The monitor <NUM> may also be integrated with a touch-screen panel or the like. Note that the monitor and/or touch screen panel can be physically coupled to a housing in which the computing device <NUM> is incorporated, such as in a tablet-type personal computer. In addition, computers such as the computing device <NUM> may also include other peripheral output devices such as speakers and printer, which may be connected through an output peripheral interface or the like.

The computer <NUM> may operate in a networked or cloud-computing environment using logical connections <NUM> to one or more remote devices, such as a remote computer. The remote computer may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <NUM>. The logical connections depicted in <FIG> include one or more local area networks (LAN) and one or more wide area networks (WAN), but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a networked or cloud-computing environment, the computer <NUM> may be connected to a public or private network through a network interface or adapter <NUM>. In some embodiments, a modem or other means for establishing communications over the network. The modem, which may be internal or external, may be connected to the system bus <NUM> via the network interface <NUM> or other appropriate mechanism. A wireless networking component such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a network. In a networked environment, program modules depicted relative to the computer <NUM>, or portions thereof, may be stored in the remote memory storage device. It may be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Claim 1:
A computer-implemented method of debugging a target process, the method comprising:
entering (<NUM>), by a debugger, a break mode while debugging a target process (<NUM>), wherein the target process comprises a virtual memory (<NUM>) that points to data stored in a physical memory (<NUM>);
characterized in that the method further comprises:
generating, by an operating system, a process snapshot (<NUM>) from the target process, wherein the process snapshot comprises a virtual memory page table (<NUM>) that is a copy of a page table of the target process at a time when the snapshot was generated, and wherein the virtual memory page table points to physical memory pages (<NUM>) that were in use when the snapshot was generated; and
performing (<NUM>), by the debugger, a function evaluation within the process snapshot.