Friday, September 30, 2005

Some devstudio tips

Hi everyone,

I sent this around at work yesterday. Its just a couple of tips about programming in Visual Studio .Net 2003.

When a project changes, dev studio offers to Reload it. This doesn't always work.

1. Most of the time the Reload button works fine when a vcproj or sln file has changed. However, in the case where a new file has been added to the project you will usually find that you have to completely close out the solution and then load it again to avoid link errors for code in the new file. Personally, I just restart dev studio in such cases.

Setting up Tool menu items to run perforce commands

2. To properly set up the Tools menu to have your perforce checkin, checkout, revert, and sync commands you need to set the following environment variable: "P4CLIENT=username". For example, I have set my P4CLIENT environment variable to "mmoore". Then you can set up commands like "c:program files\perforce\p4.exe" with arguments "diff -f $(ItemPath)". If you have logged in to perforce via p4win, you should have no problems. To be safe, I also set : "P4PORT=myperforceserver:1666", but I'm not sure if you need that.

Properly handling an environment variable change

3. Note that when you make changes to environment vairables via

"My Computer/Properties/Advanced/Environment Variables...",

you are not going to see those changes in any programs that were already running prior to that point. This can bite you in many ways, but one of the more apropos in this case is the need to restart devstudio after changing an environment variable, such as the P4CLIENT mentioned above.

* SIDE NOTE: Those who might use a filebrowser program instead of the default explorer folder browsers have to be especially cautious on the environment variable changes. If you're used to running devstudio from Directory OPUS or Explorer XP and you change an environment variable to a new value in the windows shell, you'll need to restart your file browser program so that new programs launched with inherit the updates to the environment variables.


4. Devstudio added minidumps to the mix in 7.0, which makes it easy to set up a crash handler that takes a snapshot of the stack, registers, and associated information such that the call stack can be reproduced faithfully at any time in the future. A minidump may decide to include the entire heap if desired - doing so allows you to view all aspects of memory including the values of variables not on the stack. Heap minidumps also do not need to be pointed to the original binary to load symbols - the heap info is enough. Minidumps without the heap, on the other hand, must be pointed to the original binary and its associated pdb file.

To use a minidump, you simply open it in devstudio and open it as if it were a project file. You'll see a callstack as if the program had just crashed, though of course it hasn't. :)

Hope these tips help somebody,


Tuesday, September 13, 2005

program to find which process is using a file windows

Today I was trying to delete a file on my hard drive and it came back and told me that, although it bitterly regretted it, the operating system would not be able to comply with my request because another process had the file opened and was restricting access to it. Without the proper access, the operating system cannot delete a file.

I tried my first trick, which works a good percentage of the time: I renamed the file. Or, I tried to. Instead, I got a similar message indicating even this approach of renaming the file was not possible. Often it works because the owner of the handle that has the file opened can continue to access the file so long as you simply rename it and do not attempt to delete it. I think, though I am not sure, that this method works so long as the owner of the handle does not have that handle opened for write access.

At that point, the question that is the title of this blog entry came into play: "Is there a program out there that will tell me which program or programs has a specific file opened?" If I know which process has my file held hostage I can use task manager to terminate that process and thus free up the file's permissions so that I can safely delete the file.

I did a few google searches but didn't turn up much. Disheartened, I started scanning with my good friend 'procexp.exe' - or Process Explorer - to see which one it might be. Procexp can show you which handles a given process has open, including files. As I did this manual hunting, I noticed the Find menu, which turns out to be the perfect tool for the task. Using its Find Handles... dialog, you can type in the substring to search for - which can be a portion of the filename, or the type of resource in general. For example, type 'ntuser' and you'll find all the handles opened on your system that touch anything with ntuser in it, such as the ntuser.dat log file, which every user has in Windows XP.

This feature was so usefull and cool, I just had to share. If anyone is even reading this out there, and you have a good tip of your own, please do share!


There is now ( perhaps always was) a command line utility also available at called Handle that provides a very rapid way to find open files and other handles on your system. I recommend it above procexp.exe unless you're already running procexp.exe. It is also nice, if you are like me and use a suite of unix commands for dos. Then, you can pipe the results from the handle command to whatever other command-line programs you like. For example: 'handle | grep -i insight" will show me not only what files are opened that have the word insight in their title but also all handles opened by my editor, Source Insight, because its executable name is insight.exe.