Does WinDBG purge cached pdb files after a while? - windbg

I use WinDBG a fair bit to debug dumps that testers send me. Right now, I'm experiencing very poor performance with obtaining debugging symbols from Microsoft's symbol server. I'm not the only one so I expect Microsoft are having server issues at the moment but it's highlighted something about WinDBG's symbol caching which I haven't paid much attention to before.
Very often when I open a new dump it's trying to download every pdb for all the Microsoft symbols. It caches them for the duration of my debugging session, and if I close WinDBG and open it again it often opens without having to download symbols. However if I open a dump that I was using a few days earlier it seems to have often lost the symbols that it downloaded previously. It seems to be purging old pdb files or some such..
I have my symbol path set up like this:
SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
So, question, is it possible to control how often WinDBG purges cached symbols? I'd be quite happy for it to fill a few GB with symbol files since disk is cheap...

No, symbols are not purged. I am not aware of any information that would tell WinDbg the age of symbols except the timestamp which is not reliable. The file pingme.txt is an empty file.
As mentioned by #blabb in the comments, purging would be counter-productive, given that you can download symbol packages (Microsoft) for offline use for very old symbols, e.g. Windows XP.
On my PC which I got when I joined the company, the symbols of 2014 are still there:

Related

How to convert PS1 to EXE [duplicate]

I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support

Convert PowerShell script to exe

I'm looking to convert a PS1 file to an .exe file so I can roll it out to less technical users.
I believe it'll be much easier for them if all they need to do is double-click it vs explaining how to run through PowerShell.
How can I achieve this?
Use PS2EXE instead of this online tool that forces you to upload your script and creates a security breach if you have confidential information inside your script.
There is a GUI mode available; to learn more, see the GitHub repository.
You have a few paid and unpaid solutions. I agree with last answer, do not use online tools unless you are sure they are not keeping your code and you trust them.
There are two free ones that come to mind:
PS2EXE-GUI
PS1 To EXE by F2KO (Make sure t it is the local install command line interface, not the web one)
The Paid ones are:
PowerShell Studio
ISE Steroids 2.0 Enterprise
Noted: I think the free ones should be fine for most uses. I do like PowerShell Studio though.
An update to PS2EXE tool (all versions are open-source):
The original script comes from Ingo Karstein, but the development seems to have halted in 2017. You can find his blog here, and his contribution on Microsoft Technet's forums here.
Markus Scholtes has continued the script's development, adding some useful features. You can find his post on Microsoft Technet here, and github repository here.
Powershelling's answer point you to a fork of Markus' project by Stuart Dootson (here and here), which is less maintained. The obvious difference would be the "Added support for scripts that require elevation. This inserts a suitable manifest into the executable produced by the tool. that .exe files built with his version of the script require elevation".
I'd recommend checking out Markus Scholtes' version, but beware (!) (README.md on 3rd Nov 2020):
Attention: Incorrect virus detection of PS2EXE
Some stupid idiot seems to have abused PS2EXE to compile his computer virus script. As a result, a rapidly growing number of virus scanners recognize programs created with PS2EXE as malicious programs and delete them.
There is only one hope to save the PS2EXE project: Please send your (harmless) programs created with PS2EXE via the web forms from the virus scanners' vendors for reporting false positives (I've already done it with some of them, please use only the false positive page)!
If this is not successful, then I will have to quit PS2EXE as nobody can use it anymore.
Thank you for your support

Should we deploy scrrun.dll (Windows Scripting Runtime)?

Our VB6 application relies heavily on the use of scrrun.dll (Windows Scripting Host). Until a year ago we used to deploy this dll with our installer. Since the Windows Scripitng Host is supposed to be part of Windows we removed the dll from the installation package. However, now and then surface customers who have a non functional scrrun.dll on their system and we have to help them reinstall or reregister it.
So, should we put the scrrun.dll back in the installation package? Should we perform some check on installation? Or should we just live with the fact that we have to provide hands on support to some of our customers to set their systems right?
Don't try to deploy these libraries as part of a normal setup.
Microsoft Scripting Runtime must be installed through the use of a
self-extracting .exe file. For versions of Scripting Runtime mentioned
at the beginning of this article, the only way to distribute it is to
use the complete self extracting .exe file located at the following
locations...
It is possible that some users employ an older anti-malware suite, many of which tried to disable scripting. It is more likely though that some users have managed to break their Windows installation, either themselves or by using applications improperly packaged to try to include these libraries - and blindly remove them from the system on uninstall (cough, cough - Inno).
The libraries involved have been tailored code for some time. This is why the ancient .CAB file was "recalled" long ago. There is no single copy of them intended to run on any random version of Windows, and there are no redist packs for any modern version of Windows. The correct fix is a system restore or repair install.
While this can't be blamed directly on InnoSetup because it is the result of poorly authored scripts it is frustrating enough and common enough that I won't cry when its signature is added to anti-malware suites. There are just too many poorly written examples loose in the wild copy/pasted by too many people.
I spend plenty of time undoing the damage caused by uninstalls of these applications and have grown quite weary of it. Where possible I use isolated assemblies now in self-defense, which helps a lot. Windows File Protection is getting better about preventing abusive action for system files too.
But in general you are much better off avoiding any dependency on scripting tools in an application. There isn't very much that they can do as well as straight code anyway, though it may take some time to write alternative logic.

same hash, different behavior

I have two files that give the same hash, and even the same hexdump. File A and File B start on Linux Box 1 and Linux Box 2, respectively. I then copy both files to a Windows share, and read them from a Windows machine. The files still seem to be byte-by-byte identical with the Windows utility Fc (with /b option -- binary mode). However, when I open the two different files, they appear to have different encoding (newlines/line-wrap). Why wasn't this uncovered by the hashes/hexdump/Fc?
What am I overlooking here?
Don't use wordpad for that. Actually, don't use wordpad at all. Note that Microsoft often does not keep to standards, and in many times (e.g. the browser) simply takes and informed guess at file or stream content, using the header as some kind of magic. Sometime it guesses wrong, some times it doesn't.
You could calculate the hash on the Windows machine as well, there are plenty of lightweight utilities that calculate secure hashes within windows Explorer. You could also install command line utilities such as OpenSSL on Windows (or take it a step further and install Cygwin, which I always have running on my Windows machine).
Windows has never had a real strategy regarding line endings, except keeping to it's own double-character standard. In later versions of Windows you may use Notepad which does (finally) understand Unix newlines if you must (because maybe it screws up UTF-16 this time around).

Windbg - Detecting symbols needed for a crash dump

I have a crash dump file that I need to analyze using windbg to run some tests.
Due to some restrictions I can't comment, my symbols folder can only contain the symbols needed to analyze this crash dump.
Is there a way to know the exact symbols needed by a dump? If it helps, I can first analyze this dump in another environment where all the symbols are available.
Thank you.
You can use !sym noisy to make Windbg dump out the symbol it needs and looks for.
If you set up a symbol path with a local cache, Windbg will download into the local cache path only the needed symbols.
If you load the dump on your machine, force it to load all the symbols, the lml command will show all loaded symbols and you can see each module where it loaded the symbols from, copy only those pdb files into your target restricted environment.
I'm not entirely sure if this is possible. Analyzing a dump is a dynamic process but you're looking for a static solution. It's not possible to know what symbols will be needed unless you already know what the problem is. Therefore it's not possible to know what set of symbols will be needed.
Even doing something as simple as saying that "I will only provide symbols for the DLL's which have frames on the stack" is not enough. It's possible that memory corruption or a global variable from a DLL not on the stack could influence the behavior of the program. Leaving symbols for that DLL out could prevent diagnosis of a problem.
One approach though which will yield decent results would be the following
Load up the dump in the environment where all symbols are available
Set the symbol path to the directory
run "analyze -v"
Dump the state of modules at this point and include symbols for any DLL for which windbg loaded symbols.
You can also use the command:
lml
after running "analyze -v" to display which symbols WinDbg loaded or attempted to load.