0: kd> !analyze -v
The debuggee is ready to run

I saw on the forums that a couple of poeple hit this issue and couldn't find a solution. Well, I was lucky enough, after trying these I got it back working

1: kd> .ecxr
Unable to get exception context, HRESULT 0x8000FFFF
Break instruction exception - code 80000003 (first chance)
windbg> .hh
3: kd> .cxr

So, if you hit that message, try running .ecxr and .cxr commands on your windbg command window. Hope that helps!

Hey folks, I’m a big fan of Windbg. It’s really powerful and you can do much more things than you can do with another other debugger!

In this blog post I’m going to show you different methods to start debugging with windbg.

Start by launching the process with Windbg

This is easy. If you need to debug a simple application and you have the exe path, you can launch it with Windbg either from the command line or from the UI. All you need to do is launching Windbg and clicking “Open Executable” menu item from the File menu. You can then provide executable path and arguments to the process. Once you click Open, your debugging session starts.

Start by attaching the process to Windbg

If you have a process that’s already running, you can use this option to start debugging with Windbg. This option is useful when debugging services or processes that cannot be restarted. To do so, launch the Windbg and select “Attach to a Process” menu item from the File menu. Windbg will display a list of processes that you can select any to attach it to the debugger. Once you click OK, your debugging session starts.

Start by using Gflags

This is a little bit advanced. You can use gflags.exe, a utility tool for processes, to start the process under Windbg. Here is how it works: You write the executable name to the GFLAGS under Image File tab and it displays you a bunch of options. In the below image, I launched the gflags.exe as administrator, switched to Image File tab and wrote notepad.exe as image name. When I clicked the TAB key, it displayed options associated with the notepad executable. The Debugger option should be filled to point to Windbg.exe path in your system.

Now, whenever notepad.exe launches in the system, it will be started as attached to Windbg. GFLAGS is very useful when you are debugging a process and when you don’t know when it will be started or by whom it will be started.

Start by child debugging

Windbg has a command to enable child debugging for any process. All you need to do is to write below command to the Windbg command line in parent process’ debugging session:

.childdbg 1

So, where can you use this method? Let’s assume that you are going to debug a service process running as SYSTEM. Normally, you can use the attach the process to Windbg method after service starts. However, what if you want to debug the service start up? In this case you can’t use the attach method because you would miss the service startup. You can’t use GFLAGS either because the service is running as SYSTEM and Windbg will start in another desktop (SYSTEM user’s desktop) and won’t be available to you.

So, here is what you can do:

- Attach the services.exe to Windbg by using attach to a process method.

- Run “.childdbg 1” command in the Windbg command window. This will enable the child debugging for services.exe

- Start the service you want to debug. What will happen is that new service will start and the Windbg console that’s attached to the services.exe process will break, indicating that a new process is started. Now you will have the ability to debug the new process in the same Windbg program.

Start by setting the Windbg as default postmortem debugger

You can run “Windbg –I” command from a command line tool to set your Windbg as default postmortem debugger. This is useful when running application verifier to verify your process. In case of any appverifier stop, Windbg will be automatically launched and attached to the process.

Start by setting MsiBreak environment variable

Have you ever needed to debug a custom action in your installer? Windows Installer uses MsiBreak environment variable to give you a chance to debug your custom action. Basically, you need to create an environment variable named MsiBreak and set its value to the custom action name. When the custom action is being executed during the install time, you will be asked to attach the process to the debugger. You can use attaching process to Windbg method to start debugging your custom action.

In this post, I tried to cover different methods to start debugging a process in user mode. If you haven’t tried Windbg already, I strongly recommend to start using it!

Hello everyone,

Have you heard about Server App-V? Do you want to learn more about it ? SCVMM 2012 Beta was announced at MMS this week. With the SCVMM 2012, enterprises can use a very cool feature, Server App-V, to dramatically simplify the deployment scenarios in their datacenters by taking full advantage of virtualization!

To read more about the SCVMM 2012, you can check out the team blog of SCVMM: https://blogs.technet.com/b/scvmm/ I love how these guys blog. There are a lot of good contents on it. So, give it a try and learn more about SCVMM 2012!

Now, going back to Server App-V, you should definitely check out the Server App-V team blog. It has been created on technet and the purpose of the team blog is to enlighten folks about the Server App-V, it’s purpose, use-cases, customer scenarios, benefits and so on. Here is the link to the team blog: https://blogs.technet.com/b/serverappv/ 

Are you thinking about using wsprintf method to create a string buffer? Think twice before doing anything wrong! MSDN documentation explicitly warns programmers to not use this API.

So, what alternative we can use instead?

sstream header gives us wstringstream class to create our own string streams. It’s easy, convenient and object oriented. Let’s try a simple example:

Above example demonstrates how you can concatenate a string buffer and an integer to form a single string.

In short, do not use banned APIs such as wsprintf. There are multiple ways of doing something and choose the safest and cleanest one!

This post is all about how to avoid freeing a memory block that is allocated by us manually. Attempting to free the allocations manually may result in memory leaks, access violations, unreadable code, and maintenance problems. For example, look at the below code piece:

Do you see the problem(s) here ? Anytime something goes wrong, we have to remember to delete the pointer. Otherwise memory will be leaked. What happens if someone else visits this code and modifies it in the future ? It’s very likely that another return path will be introduced and ptr won’t be freed. Even if all the delete operators are used correctly, an inner method may throw intentionally or unintentionally and leave the memory allocated in the process. One final problem is the readability of this code. We make it unnecessarily longer and hard to read by trying to handle all the delete operations. What would our function look like if it allocates multiple variables!

Here is another typical problem:

First, I am really against using raw pointers to allocate memory. Second, passing the raw pointer from one scope to another is something we should avoid. In some cases, multiple objects may want to share same memory block. For example, if you have an object dynamically created in the heap and if multiple objects want to consume this object, you start passing this object around..

To make our operations safer and cleaner we can use shared_ptr when we create the objects. shared_ptr holds a reference count to the object and frees it when the last reference goes away. Two popular shared_ptr classes are in the tr1 and boost library.

This is much better. We allocate a memory block for MyClass object by using a shared_ptr. So we don’t need to call delete operator on it; shared_ptr will automatically free it when the last reference goes out of scope. foo method’s input parameter is also a type of shared_ptr so when we pass the ptr object to the foo, it’s reference count will increment   by one preventing other shared_ptr objects freeing the MyClass object.

Sometimes, all we need to do is to create a buffer and use it in the same function and get rid of it quickly. In these cases, we can either use auto_ptr or a vector object.

auto_ptr is useful when we need to allocate a class object. For example; auto_ptr<MyClass> ptr = new MyClass();

When auto_ptr goes out of scope, it will delete the object automatically for us. Unlike shared_ptr, auto_ptr does not keep a reference count so you should not pass auto_ptrs around. This will very likely cause an access violation since each auto_ptr destructor will try to free the memory block.

vector object is useful when you want to allocate an array of primitive type variables. I generally use vector class to create string buffers or BYTE buffers. When object goes out of scope, it will again free the memory for us.  std::vector<wchar_t> buffer(size, L’\0’); creates a buffer of wchar_t in size length and fills the buffer with NULLs for us.

In conclusion, avoid using raw pointers and delete operator in your code. There are beautiful smart pointers and techniques to do memory management automatically.

As technology advances, applications increase their complexity. As a result, installers deploy more and more files and folders to the install directories.  Software developers should not rely on the Window’s MAX_PATH constant when developing their applications. Many Windows APIs don’t support file paths that are longer than MAX_PATH in length directly. However, they do support these files under some rules. I recommend you to follow this guideline when working with file APIs.

1 : Never use MAX_PATH constant in the code. Most of us tend to allocate buffers with a magic number. However, this is not a good practice as it may introduce security threats and reduce the robustness of program. Instead, use a vector object as a buffer. You will have the power of changing its size based on your file path length.

2 : Prepend \\?\ characters to the file paths that are longer than MAX_PATH. Most Windows APIs support file paths that are longer than MAX_PATH in length IFF file path contains \\?\ prefix. However, do not prepend this prefix to the file paths that are less than MAX_PATH in length as prepending this prefix causes APIs to skip some validations that are valuable for the program.

3: Of course, do not use Windows APIs that do not support file paths that are longer than MAX_PATH in length. Some APIs fail even if you prepend the \\?\ prefix to the file path. SHFileOperation is one example to these APIs.

4: Wrap the Windows APIs to your own functions so that you will have one entry to control if you need to make any change to the API. 

5: Write unit test! To ensure that your code works fine for any file paths with any lengths, write your unit test and validate your code.

Did I tell you Windbg is a great tool to debug native processes ? However, we still have to know how to approach the problem. Today, I wanted to debug user mode process crash. When I see a crash, I generally start the process under windbg and run the following command from debugger command window:

sxe eh

This enables the windbg catching first chance exceptions. Normally, first chance exceptions don’t cause a crash so you may not need this command at all but I like seeing what’s going on during execution. If first chance exceptions could not be handled, a second chance exception occurs and now you are in trouble. If you don’t have debugger attached to your process, you see that Window’s pop-up message saying that your process died…

Anyway, catching second-chance exceptions are easy. Windbg does this for you. However, today I encountered with another type of crash. The process just died. No crash message, no dump file, no nothing…. As usual I launched my dear lover, windbg, and attached to the process. I run the process and it died again and I didn’t receive any exception message from the debugger output. I then tried to put breakpoint to ExitProcess function and launched process monitor to see what was going on during crash. Still no luck…

Later, I happened to remember that some windows APIs call invoke_watson when an exception occurs. If you also register your unhandled exception filter, your filter can get called during invoke watson call. After a quick bing, I found the API that’s responsible for executing the filter and put a breakpoint to the API:

bp kernel32!UnhandledExceptionFilter

I let my process go again and voila! The breakpoint hit and I checked the call stack. In my case, the error was coming from swprintf_s API. It tends to validate parameters and call invalid parameter handler if buffer is not allocated in enough size. So, at the end of the day I was happy because I could debug my case and I used a different method to debug a process crash…