none
Why running listdlls.exe causes listdlls64.exe gone RRS feed

  • Question

  • I just ran listdlls.exe on Windows 10 and noticed that it caused listdlls64.exe to be deleted upon completion.

    Is it by design?

    Thanks

    Friday, July 19, 2019 8:01 PM

Answers

  • OK, then I don't understand what for the 64-bit executables would be provided separately (in the suite), if the 32-bit ones already contain both versions?


    Here is part of a quote from an older post from Kyle Hanslovan:

    The *64.exe versions of the Sysinternals apps are designed for Nano Server editions of Windows which do not include the 32-bit subsystem. In all other cases, the non-*64.exe versions should work as expected (either by using "Sysnative" paths or actually dropping a 64-bit binary to disk and running that instead.
    • Edited by CacheL1 Monday, July 22, 2019 10:58 PM
    • Marked as answer by lavrncbi Tuesday, July 23, 2019 6:13 PM
    Monday, July 22, 2019 10:54 PM

All replies

  • Yes, it is..

    If you downloaded the full suite from live.sysinternals.com or from the Technet page, you will find both the file so they can be used immediately on a 64 bit system.

    But if you start the 32 bit version, as with almost all the Sysinternals executable, it will check the bitness and if it is is run on a 64 bit OS it will extract the 64 bit version, unless if by any chance it is already there..

    Like all the tools, when finished using it, it will delete the 64 bit version from the folder..

    Have a look at a Procmon log which show exactly that moment..

    HTH
    -mario

    Friday, July 19, 2019 9:11 PM
  • I am sorry, I don't understand your response, nor I see any logic in deleting a native 64-bit executable on a 64 bit OS:

    After I install the suite, I have two executables, 32 and 64 bit:

    $ file listdlls.exe
    listdlls.exe: PE32 executable (console) Intel 80386, for MS Windows

    $ file listdlls64.exe
    listdlls64.exe: PE32+ executable (console) x86-64, for MS Windows

    Once I ran listdlls.exe, I end up with only one executable, which is 32 bit:

    $ file listdlls.exe
    listdlls.exe: PE32 executable (console) Intel 80386, for MS Windows

    Thats' absurd.


    • Edited by lavrncbi Monday, July 22, 2019 2:58 PM
    Monday, July 22, 2019 2:57 PM
  • The logic is that you have a 32 bit executable that contains both versions, 32 and 64 bit, so you don't need the 64 bit version available on the disk, because it is inside the 32 bit version.

    So, every Sysinternals tools when started from a 32 bit version, check if it is available the 64 bit version (like in your case, because you downloaded the full suite), if it is it uses that, if it is not available, then it extract from the 32 bit the 64 bit version, and run this new exe from the temp folder. When the 64 bit end its execution, the 32 bit version perform the clean up of the system. If it extracted the 64 bit to a temp location it deletes that, if it didn't extract the file because it find it in the same folder it deletes that too..

    If you want to maintain both version in the folder, on a 64 bit OS you MUST run the 64 bit version.. If you run the 32 bit, it will always perform the clean up procedure deleting the 64 bit version..

    Again, I remember you that the fact that you find both versions is because that way you can run the 64 bit directly.. If you run the 32 bit the above will happen.. and the 64 bit version will be deleted during the cleanup phase..

    HTH
    -mario

    Monday, July 22, 2019 3:05 PM
  • OK, then I don't understand what for the 64-bit executables would be provided separately (in the suite), if the 32-bit ones already contain both versions?
    • Edited by lavrncbi Monday, July 22, 2019 6:24 PM
    Monday, July 22, 2019 6:23 PM
  • Because having them already extracted enables you to run them directly, by example via script, without the need to go through the whole process of running the 32 bit version, wait for it to discover the bitness of the OS, extract the 64 bit version and run that..

    It's quicker :-)
    It'a a shortcut.. 
    It's a simpler process.. There are a lot of advantages..

    Thanks!
    -mario

    Monday, July 22, 2019 7:22 PM
  • OK, then I don't understand what for the 64-bit executables would be provided separately (in the suite), if the 32-bit ones already contain both versions?


    Here is part of a quote from an older post from Kyle Hanslovan:

    The *64.exe versions of the Sysinternals apps are designed for Nano Server editions of Windows which do not include the 32-bit subsystem. In all other cases, the non-*64.exe versions should work as expected (either by using "Sysnative" paths or actually dropping a 64-bit binary to disk and running that instead.
    • Edited by CacheL1 Monday, July 22, 2019 10:58 PM
    • Marked as answer by lavrncbi Tuesday, July 23, 2019 6:13 PM
    Monday, July 22, 2019 10:54 PM
  • Quicker?  They are interactive tools, so it does not really matter if it takes +1ms more to launch, nobody would even bother to notice

    Shortcut?  A very fragile one indeed; one misstep by running non-64 version kills it!

    A lot of advantages?  Hmm... If that was so why the non-64 version would remove the 64 one?

    Tuesday, July 23, 2019 4:57 AM
  • Thank you.
    Tuesday, July 23, 2019 4:57 AM
  • "64.exe versions of the Sysinternals apps are designed for Nano Server editions of Windows which do not include the 32-bit subsystem"

    Didn't know this.. wonderful.. learned something new..

    Thanks!
    -mario 

    Tuesday, July 23, 2019 6:56 AM
  • Take also into account that sometimes, because of the way the 32 bit app is packaged, and the process of extracting the 64 bit version, the app is blocked from antivirus/antimalaware and so having the 64 bit exe available help also in those cases..

    Anyway, the nano server reason, that I honestly didn't know, is definitely the reason.

    -mario

     

     
    Tuesday, July 23, 2019 7:06 AM
  • Ok, now that we know the reason behind, I just had a look at all the utility and looks like very few of them are now packaged like many years ago with both the 32 and 64 bit inside the same binaries..

    Looks like only Procesxp Procmon handle and listdlls are still packaged that way..

    But Processxp procmon and handle extract the 64 bit version of the file in the temp folder, while listdll uses the local copy in the sysinternal folder, and so when finished it delete the 64 bit version..

    So at this point it looks like a bug.. because its behavior is different from all the others.
    MarkC what do you think? Probably you need to update this to behave like the others tools..

    Thanks
    -mario

    

    Tuesday, July 23, 2019 9:00 AM
  • > the app is blocked from antivirus/antimalaware and so having the 64 bit exe available help also in those cases.

    Oh really?  Is that why the 64-bit executable gets deleted whenever there's a chance?

    Tuesday, July 23, 2019 6:02 PM
  • no, that's another reason why I think it is available in the folder other than being provided for nano server.

    As I told you above, after taking into account the nano server reason, I had a look at all the tools and now only 6 tools remain to use the old packaging model.. four of them now take into consideration the fact that an *64.exe version could be available in the same folder and extract the 64 bit version in the temp folder. LIstdlls.exe and livekd.exe seems to be the last two working completely the old ways, and now so should be fixed..

    MarkC, can you please add them to the list of app to fix??

    Thanks!
    -mario


    • Edited by mariora_ Wednesday, July 24, 2019 7:12 AM
    Wednesday, July 24, 2019 7:12 AM