ab origine ... : troubleshooting

Norton’s quality of code in drivers

V. S. — Tue, 07 Jul 2009 08:25:00 GMT

Life of every driver developer is complicated by the fact that the code you write should be stable (read: bugs free) and compatible with any other third party drivers. It is very important for any driver to be bugs free, as any error in kernel leads ...(read more)

SMB traffic not captured in TDI filter driver

V. S. — Thu, 09 Oct 2008 06:46:00 GMT

Recently I met a problem in one of my TDI filters when filtering SMB traffic. The filter driver was able to see outgoing TDI_CONNECT requests to 137 and 445 ports, but during the heavy file upload there was no TDI_SEND requests issued. Please read the...(read more)

Undeletable bug in VS2008?

V. S. — Wed, 27 Aug 2008 01:33:00 GMT

I see this bug for a quite a long time, starting from VS2005. To illustrate the problem: 1. Go to project properties, open some tab 2. Do not close the property dialog windows simply change the focus by clicking in code editor [...] Please read the post...(read more)

Bug in MSDN: TDI_EVENT_RECEIVE_DATAGRAM & it's handler

V. S. — Thu, 17 Jan 2008 18:03:00 GMT

If you ever wanted to handle TDI_EVENT_RECEIVE_DATAGRAM ( http://msdn2.microsoft.com/en-us/library/ms801156.aspx ) event handler in TDI, you would notice that it's declaration is a bit strange( http://msdn2.microsoft.com/en-us/library/ms801622.aspx...(read more)

DRIVER_VERIFIER_IOMANAGER_VIOLATION in Windows Server 2003 SP2 with latest updates ON

V. S. — Wed, 16 Jan 2008 20:39:00 GMT

Recently, I've received following error when trying to test my TDI filter driver on Server 2003 SP2 with latest updates ON: DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9) Arguments: Arg1: 00000208, (Fatal error) This IRP is about to run out of stack locations...(read more)

explorer.exe is in danger :)

V. S. — Thu, 27 Dec 2007 19:41:00 GMT

Kaspersky ( http://www.kaspersky.com/ ) recently released a signature update that treats explore.exe as a virus. This false signature may affect those people who set the option 'delete virus' ON - it let's anvtivirus delete the suspicious...(read more)

The case of Task Manager that does not kill

V. S. — Thu, 20 Dec 2007 21:42:00 GMT

Quite long time ago, my friend Vadym Stetsiak described a bug of Task Manager , which allows to disallow (!) the killing of a process, if it's name is lsass.exe. In order to test this bug, you can rename any executable file into lsass.exe, run it...(read more)

A shame on Kaspersky ...

V. S. — Thu, 23 Aug 2007 18:34:00 GMT

As one of the stages in my work, I do tests of different antiviruses with components I develop. This allows me to handle incompatibility issues, profiling BSODS and other critical errors that might appear during software lifecycle ;) These days I was...(read more)

Undefeatable files & folders in Windows XP SP2 - a bug in SHFileOperationW

V. S. — Sat, 14 Jul 2007 23:01:00 GMT

Recently I was surprised with one interesting behavior of my Windows XP box. I was playing with long name files and noticed that major part of my shell extensions do not work with files, whose path is longer then 260 symbols. I also noticed, that Windows...(read more)

Bug in wininet: RETR command is not supported since IE7 release

V. S. — Fri, 11 May 2007 08:32:00 GMT

If your FTP client relies on Wininet and supports resuming of downloads then it fail to work under IE7 because RETR command is not working properly when you invoke it using FtpCommand(…) function. The function fails with access violation, outputting the...(read more)

IE7 release still beats us

V. S. — Sun, 17 Dec 2006 11:51:00 GMT

I participate in wininet NG from time to time. Since IE7 release, the major part of issues that I read there is connected with the changes introduced by IE7. Fortunatly for us, WNDP team is ready to investigate any bug you'll find. Of course, you can...(read more)

The case of IE7 that would not run

V. S. — Sat, 02 Dec 2006 00:27:00 GMT

Yesterday I met an interesting behavior of IE7. On one of my computer which runs Windows Server 2003 SP1 I was trying to publish a post to my blog ('the power of IDA'). But I failed to do that. IE7 was crashing when I tried to write something in the editor...(read more)

Why does Windows do not provide more flexible API for Shell Context Menu Handlers?

V. S. — Fri, 17 Nov 2006 00:01:00 GMT

Recently, I came across an interesting situation.

My PC (XP SP2) was making some calculations. CPU activity was high. I was surfing through my folders and clicked on one of them using right button of the mouse. The context menu appeared after 10-20 seconds … “Why does it takes so long” - I asked myself? This question leaded me to investigations …

Windows Shell supports so called ‘shell extensions’ which allow extending the functionality of shell. It allows 3^rd party products to write custom menu handlers that append own menu items to shell menu and help user easily use some feature of the product. Typical example of such approach is WinRar, WinZip applications. Shell extension is represented as COM component that implements several COM interfaces. I will concentrate here on IShellExtInit interface mostly.

So, when I click on my folders I see the following picture:

As you can see on screenshot I have WinRar shell extension installed on my PC. Seems like there is something inside it’s handler that cause delays.

Each shell extension object implements IShellExtInit interface. According to documentation, IShellExtInit has method named Initialize with the following params:

HRESULT Initialize(LPCITEMIDLIST pidlFolder, IDataObject *pdtobj,
HKEY hkeyProgID);

The IDataObject object passed to the method allows obtaining the path of folder user clicked on. One is able to get the handle to structure that contains file names and finally pass that handle to DragQueryFile function to get the path. DragQueryFile function is defined with following parameters:

INT DragQueryFile(HDROP hDrop, UINT iFile, LPTSTR lpszFile,
UINT cch);

I can set breakpoint in WinDbg to DrawQueryFileA/ DrawQueryFileW functions to see where they are called. This gives me ability to check what extensions are calling this function, and what is going on in Initialize method of each extension.

Following commands do that:

0:001> bp DragQueryFileA
0:001> bp DragQueryFileW

Here is what I see in command line after executing “bl”:

Now I am going to click on folder and see where DrawQueryFile is called. I click on a folder, and I see the following places where the rarext.dll calls DrawQueryFile:

; first call
02d0c44d 6a00            push    0
02d0c44f 6a00            push    0
02d0c451 6aff            push    0FFFFFFFFh
02d0c453 ff75d4          push    dword ptr [ebp-2Ch]
02d0c456 e881a90000      call    rarext!DllCanUnloadNow+0xc0ac (02d16ddc)

; second call
02d0c491 6800040000      push    400h
02d0c496 8d85bcfbffff    lea     eax,[ebp-444h]
02d0c49c 50              push    eax
02d0c49d 8bfb            mov    edi,ebx
02d0c49f 57              push   edi
02d0c4a0 ff75d4          push    dword ptr [ebp-2Ch]
02d0c4a3 e834a90000      call    rarext!DllCanUnloadNow+0xc0ac (02d16ddc)

; third call
02d0c4b1 6800080000      push    800h
02d0c4b6 8d85bcf3ffff    lea     eax,[ebp-0C44h]
02d0c4bc 50              push    eax
02d0c4bd 57              push    edi
02d0c4be ff75d4          push    dword ptr [ebp-2Ch]
02d0c4c1 e81ca90000      call    rarext!DllCanUnloadNow+0xc0b2 (02d16de2)

In all cases the intstruction «call rarext!DllCanUnloadNow+address” is mapped to the call to DragQueryFile(A|W). Following code at rarext!DllCanUnloadNow+address shows that:

02d16ddc jmp dword ptr [rarext!__CPPdebugHook+0xc1bc (02d233e8)] ds:0023:02d233e8={SHELL32!DragQueryFileA (7ca73fb3)}

02d16de2 jmp dword ptr [rarext!__CPPdebugHook+0xc1c0 (02d233ec)] ds:0023:02d233ec={SHELL32!DragQueryFileW (7ca1fcee)}

Let me do some explanations on what is going in the code mentioned above. The first call is used to obtain the number of files user selected. It can be seen by the 0FFFFFFFFh value passed to DragQueryFile as iFile parameter. According to documentation:

- iFile
Index of the file to query. If the value of the iFile parameter is 0xFFFFFFFF, DragQueryFile returns a count of the files dropped.

Second call is made to obtain the ANSI version of path and the third call is made to obtain the UNICODE version of path. So pity, that developers of WinRar do not know what MultiByteToWideChar do and that it’s much faster then calling DragQueryFileW function. However, I want to concentrate on another issue.

In IShellExtInit::Initialize handler any shell extension almost always does the same things. It calls DragQueryFile to obtain the number of selected files, and then call DragQueryFile to query the path to a file. Imagine, that I have 10 shell extensions that need to know what file was selected by the user. Most likely they will implement the same functionality in its code. The list of following operations will be performed:

- call DragQueryFile to get number of selected files

- call DragQueryFile in a loop for each file to get it’s path

- do some logics.

Graphically, this can be represented in the following way:

From this scheme you can see that most shell extensions do almost the same steps in order to get the list of selected files. I wonder, why Shell team did not make some more flexible and efficient solution that allows to avoid this overhead?

For example, by passing the list of selected files into the Initialize function. This will significantly decrease the amount of code need to be written by shell extensions writers and, on the other side, it will be more efficient because there will be no need to make a huge amount of calls to DragQueryFile for each shell extension module.