Those who voted for "I don't log errors in my apps" must really hate themselves. Or, at the very least, I would hate working with their code.
OTOH, there is such a thing as an unreadable log file. Logging is like commenting - you need to be smart about it. Too much of it and it just gets in the way, and you start wishing it wasn't there at all.
The BugTrap library mentioned at codeproject (and now on GitHub) is excellent for recording and logging crashes.
<a href="https://www.codeproject.com/Articles/14618/Catch-All-Bugs-with-BugTrap">Catch All Bugs with BugTrap!</a>[<a href="https://www.codeproject.com/Articles/14618/Catch-All-Bugs-with-BugTrap" target="_blank" title="New Window">^</a>]
<a href="https://github.com/bchavez/BugTrap">GitHub - bchavez/BugTrap: BugTrap: Catch unhandled exceptions in unmanaged and managed .NET code.</a>[<a href="https://github.com/bchavez/BugTrap" target="_blank" title="New Window">^</a>]
For other things (non-crashes) I log to file generally
As a freelancer I'd always done some basic logging of all the apps I developed. Then a client - later to become a very significant client for me - asked me to take on support of his main line-of-business application. I installed some basic logging / reporting and discovered about 20% of transactions were failing! (The nature of the app meant that potential customers had no incentive / method to report failures). He had no idea of the scale of the problems which were losing him £ks per week. From there I enhanced the logging and developed a standard logging routine that I've included in all web applications / sites since. Serious errors trigger an email to me so I can often fix an error before the client is aware.
Someone above says they rely on the user taking a screenshot of error message etc. All very well but this doesn't trap environmental info (e.g. cookies, browser config, IP address, session contents etc.. etc..) which can make a vital difference when it comes to debugging.
I log to database (with a failover to flatfile if d/b is unavailable) which makes querying/filtering much easier to extract stats / spot trends etc..
I started on the PDP-11 and wrote mostly batch processing systems.
Logs were all we had. We used a character prefix for Error,Warning,or Informational.
My first PC apps did not log, but as complexity grew under windows, we started logging.
We also found OutputDebugString() (ODS), and used that with our logging if an environment variable was set, so we could catch the details.
The hardest thing was log rotation (because we did fill a few hard disks over many years)...
The last place I was at did not do logging until I got there, they look back and wonder about the lost hours they wasted looking into issues... Because we see them now. Very easily.
But in the rare occasions that they do - I log the error to a file, using an API that allows us to filter types and severities of errors that will be logged.
Using the O/S' error logging mechanism is a problem - clients can't easily send you the log.
Using 3rd-party error logging is also a problem - most clients don't want their stuff on the cloud.
That leaves various local options, which all translate to writing stuff to a file.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
I did write something that we now use in all of our applications that used log4net to write to various outputs (file, database, console). Have just switched to NLog as it appears to be the fastest and most reliable.