Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ExtractIconEx locks executables on Netware server

Status
Not open for further replies.

MagicFrisbee

Programmer
Feb 22, 2006
74
0
0
US
I have a user that is on Windows 7, 64-bit, and is running my 32-bit application written in Delphi 2010. I am using the ExtractIconEx shell command to extract the icons of programs out on a Netware server. For all other 64-bit clients (Vista and 7), this works as expected. On his machine, however, it actually locks the file and keeps the lock, long after the program has executed. For other users, this lock is acquired and released VERY quickly. I have tried many one- and two-line fixes, but I can't figure out what the problem is. Maybe it's something in my code, maybe it's something about his machine.

What I've tried: Accessing the .exe by IP address and by UNC path, testing GetSystemMetrics to make sure big icons are 32 x 32 and small icons are 16 x 16, made sure that the icons and icon handles ARE freed when they're supposed to.

Here's the code:

Code:
procedure TForm1.Button1Click(Sender: TObject);
var
  FilePath: String;
  HLargeIco, HSmallIco: HICON;
  FLargeIcon, FSmallIcon: TIcon;
begin
  FilePath := '\\<IPAddress>\Something.exe';
  if ExtractIconEx( PChar(FilePath), 0, HLargeIco, HSmallIco, 1 ) = 2 then
  begin
    FLargeIcon := TIcon.Create;
    FSmallIcon := TIcon.Create;
    try
      FLargeIcon.Handle := HLargeIco;
      FSmallIcon.Handle := HSmallIco;
      imgLargeIcon.Picture.Icon := FLargeIcon;
      imgSmallIcon.Picture.Icon := FSmallIcon;
    finally
      FLargeIcon.Free;
      FSmallIcon.Free;
    end;
  end
  else
  begin
    DestroyIcon( HLargeIco );
    DestroyIcon( HSmallIco );
  end;
end;

With the executables locked, we can't update them on the server. You know how it goes. Any suggestions or "try-this"es are appreciated.

"Roj"

GIS Programmer
City of Orem, UT
 
I have not really an idea here, the code looks correct according to MSDN. I would try to use procmon and trace a good working computer and then the "bad" computer and spot the difference!

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
 
From looking at your code, it seems more proper to do this ("You must destroy all icons extracted by ExtractIconEx by calling the DestroyIcon function." ). Note the main change is that by the logic you have you only destroy the icon resources ExtractIconEx creates if the call is not successful. My thought is that you wouldn't need to be concerned if it is not.

Code:
  if ExtractIconEx( PChar(FilePath), 0, HLargeIco, HSmallIco, 1 ) = 2 then
    begin
      FLargeIcon := TIcon.Create;
      FSmallIcon := TIcon.Create;
      try
        FLargeIcon.Handle := HLargeIco;
        FSmallIcon.Handle := HSmallIco;
        imgLargeIcon.Picture.Icon := FLargeIcon;
        imgSmallIcon.Picture.Icon := FSmallIcon;
      finally
        FLargeIcon.Free;
        FSmallIcon.Free;
        DestroyIcon( HLargeIco );
        DestroyIcon( HSmallIco );
      end;
    end;

HTH.

I'm waiting for the white paper entitled "Finding Employment in the Era of Occupational Irrelevancy
 
Glen999,

I'm not checking to see if the call is successful. I'm checking to see if the call returned exactly two icons. If it returned 0, 1, 3, or more, then I think I should call DestroyIcon.

Also, the reason I don't call DestroyIcon if it IS succesful is that the VCL does this for me when TIcon is freed in my finally block. You can see in the TIcon destructor that it releases private member FImage, of type TIconImage, which inherits from TSharedImage. TSharedImage's Release method calls FreeHandle, which is overridden in TIconImage. That is what ultimately calls DestroyIcon, so that's covered for me.

I'll have my user run ProcMon on the little executable I wrote for him which ONLY gets the icon of three executables out on the network. We'll see what the log looks like on Monday.

Thanks for pitching in so far, you two.

GIS Programmer
City of Orem, UT
 
So, I'm looking at the process log of the simple program I wrote--the one that just calls ExtractIconEx on three executables on the network. Even for such a simple program, there sure are a lot of messages (about 1200 of them). There are some differences between our log files:

1) In my log, it's accessing the directory by mapped drive letter. He has no such mapping to that server, and it's accessing by IP address, just as it is hard-coded in Delphi.

2) He has a few results that say "FAST IO DISALLOWED", while mine doesn't. These results have no detail information. There are 5 such results for each executable and 16 successes, while mine contains 13 successes per executable.

Needless to say, I don't know what to do different in my code and still don't know why it's only his machine that locks the executables just to read an icon and leave. Any suggestions?

GIS Programmer
City of Orem, UT
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top