GetFinalPathNameByHandle API Hungs

GetFinalPathNameByHandle is an new API introduced in windows vista. As you can read from MSDN, the purpose of this API is to return the file name corresponding to a file handle .

Some months back, I have written a small utility OpenedFileFinder which list all the file that are opened under a certain folder. While writing this application,the main problem I came across was to get the file name from the handle. Initially I used a function called NtQueryObject(). But the problem with this API is that if we try to query the details for certain object such as pipes, directory handles etc, it will hangs. So in my application finally I have to introduce a driver to get round of this hanging problem. When I found the new GetFinalPathNameByHandle(), I was so happy and I thought at least I can avoid the driver in the vista. So I had a try on this API. But I came to find that this API also have the same hanging problem which I described earlier.

It seems the GetFinalPathNameByHandle is also using the same NtQueryObject() to get the file name and so it hangs. Any how, I have reported this bug to the microsoft connect. Let us see how they solve the problem.

Another API, that worth mentioning here is GetFileInformationByHandleEx(), which is also a new API introduced in Vista. Using this API also, I can get the file name from a handle. So I decided to check whether the same problem exists in this API also. Surprisingly it worked fine. And in MSDN also it is mentioned that it uses a driver for attaining the task. So I highly suggest every one to use GetFileInformationByHandleEx() API instead of GetFinalPathNameByHandle().

__asm int 3 in template function ( in VC6 )

We usually use __asm int 3 in the code to hard code break points. But have you tried setting a __asm int 3 in a template function? Like...

template<class T> int Testfunc( T Obj )
{
__asm int 3;
return Obj++;
}

void main()
{
Testfunc( 1 );
};

The above code will never get compiled in vc6. It will generate the below error

"fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 1794)
Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
Generating Code...Command line warning D4028 : minimal rebuild failure, reverting to normal build
Error executing cl.exe."

But the same code will compile fine in later versions of visual studio. Seems they have fixed the bug :)

WM_DEVICECHANGE problem

In one our Projects at company, we used WM_DEVICECHANGE message to detect the arrival and removal of USB devices. The application was supposed to run on a machine in which will be running along with several other utility applications. Some months after the project delivery, client reported that, sometimes even if a USB device is plugged in, it is not detected. Problem problem.....

After some investigations we found that if we make the window a top-level window (HWND_TOPMOST), there is no such problems. But what’s the relation between the z-order and the above problem. Later we got few more points to identify the relation.

1. The WM_DEVICECHANGE is send to all the top-level windows according to their z-order. That is the window at the top most position receives the message first, then only the window below it and so one.

2. If a window got a WM_DEVICECHANGE and if it didn’t process the message with in a period (in my machine I think it was 20 secs), the message will not reach to the subsequent windows under it.

Now everything became clear to us, some window whose z-order is greater than our application window might have hung or didn’t process the message within 20 seconds. Thus our window didn’t get a chance. Also when we made our window top level it will be one of the first window's to get WM_DEVICECHANGE message so reducing the number of windows above it to get hung. How ever we didn't find a proper solution for this and moved to an alternative method to detect device arrival and removal.

I think windows might not be using the BroadcastSystemMessage() function with the BSF_FORCEIFHUNG flag, while sending the WM_DEVICECHANGE message.

Bug in Rich Edit control

Basically this not a vc++ bug. Its actually a bug in the RichEdit control so the bug belongs to windows.

Check the picture...

What you see inside the red circle is the caret of rich edit control. It passed the boundaries of rich edit control and moved to the dialog.

Step to reproduce.

1. Create a dialog based application and place a rich edit control on it.
2. Give the Multi line and Auto HSCROLL style.
3. Now run the application and click inside the rich edit, and keep on pressing space bar. You can see the caret crossing the boundary of rich edit and starts moving through the dialog.

This problem exists in vista and XP. But I didn't find a place to report this bug to Microsoft. I searched the whole internet to find some one already reported this problem. But coudn't find any. I dont know why such a problem haven't been noticed for the past 12 years( 12 years because I think the problem exists in the rich edit of 95 also ).