Archive for the ‘ Win32 ’ Category

Scenario: You have a 32-bit managed process running on a 64-bit machine. The process crashes sometimes. The customer created a crash dump in the Task Manager and sent it to you. You try to open it in the VS Debugger, but realize that the call stack looks really strange and does not contain any useful information. What’s the problem?
Read the rest of this entry

Debugging of Windows Services in general is not an easy task. Due to their nature Windows Services require some tricks from a developer. One of the most hardest problem with Windows Services is the crashes in the production environment due to unhandled exceptions in the program, e.g. access violation, division by zero, etc. In such situations crash dumps are invaluable. Of course, you should always keep in mind to save the binaries and debug symbols for each build and do correct versioning. Some developers include exception handlers right into Windows Services, so the program itself can write a crash dump. Another option is to write an external watch-dog application (usually, another small Windows Service, which controls the execution of main Service and writes a mini dump in case of problems).
Read the rest of this entry

Recently, I’ve faced with a problem when suddenly I started getting error messages loading a project from the Team Foundation Server. The solution consists of 5 projects, and during loading of the solution one of the project was not loaded and I received the error message “The project file ‘ ‘ has been moved, renamed or is not on your computer“. It took me a while to solve the problem. It seems to be a bug in the Visual Studio / Team Foundation Server. The problem is that the binding information was not correctly saved in the .suo file.
Read the rest of this entry

In Visual Studio 2005 / 2008 you can enable Code Analysis of your Unmanaged C++ project. The Code Analysis gives useful information of what part of your code does not meet the quality criteria. However, the Code Analysis also performs analysis of all system header files, which are used in the project. As it’s least likely that system header files will be modified by developers, this behavior is undesirable. For instance, Code Analysis will display a lot of messages compiling WTL header files.
Read the rest of this entry

There is no difference in project files (.vcproj) except the version number, you can easily open projects created with VS2005 in VS.NET 2003 by modyfing the version number of the project using the text editor.

IMPORTANT
Unfortunately, solution files (.sln) in VS2005 and VS.NET 2003 have different formats and there is no utilities available to convert solution files from VS2005 to VS.NET 2003 format. So you must create a new solution in VS.NET 2003 and then add converted projects.

Read the rest of this entry

STL containers like vector or list are harder to debug in the VS.NET 2003, because the VS.NET 2003 Debugger has no direct support for STL containers in the Watch window.
Instead you have to work with the members of the corresponding container types.

Here is a couple of tricks on how you can view the content of STL vectors and lists.
Read the rest of this entry

If you ever programmed networking applications then you should know that it is impossible to control the timeout for blocking sockets on calling connect() function. This timeout is controlled by the operating system and may last up to 45 seconds when you want to connect to a non-existing host. Since blocking sockets are very attractive due to their simplicity in usage comparing to non-blocking (asynchronous) sockets, such a limitation disappoints many developers. You can change the value of timeout globally for the system, but I would like to warn you to avoid making any changes of the operating systems, as these changes will affect ALL networking applications running on your computer. In most cases, such a behavior is not desired.

In order to solve this problem you can use the following trick.
Read the rest of this entry

An MFC application generated using the Project Wizard of the VS2005 by default uses a Unicode character set for the project. If you are using __argv to access the command line arguments this might cause an application crash.

The following code illustrates the problem:
Read the rest of this entry

This article demonstrates the syntax higtlighting for different languages.

Please test it with your browser.

Read the rest of this entry