Your boss reports an issue, and gently asks you to fix it:

You do not know the location of the button (real button in elevator, or virtual in web), but it should be a virtual one as you are most likely a Sitecore developer if reading the blog.

You hope the button to be located in the site you manage, as why would your boss contact you otherwise ?

You definitely need more contextual information to resolve the case.

Sitecore Support Package Generator saves the day, since it can collect tons of data fast.

BONUS The Sitecore Diagnostics Toolset application can analyze SSPG packages for FAQ issues (f.e. Sitecore configuration omissions, known issues symptoms), so you might just need to review the resulting report and the issue resolved :)

Sitecore configuration - Always

It`s a good practice to have a snapshot of Sitecore configuration before, and after deployment.

SIM has Showconfig tool (produces showconfig) without actually starting the Sitecore.

Thereby you can compare fresh merged configuration with an old one, or one from clean CMS via WinMerge to find either omissions, or non-standard setting values.

---

Sitecore logs - Always

Thanks to Sitecore prints all exceptions to log SCLA with time filter should be used find clues.

---

Sitecore counters - Not really

In vast majority of setups Sitecore does not have either permissions, or counters not installed =\

---

Sitecore version information - Always

Fastest way to see if any hotfix is installed.

---

IIS Pool info - Always

Corrupted indexes, file-based caches in case Maximum Worker Processes is not 1; Random CMS restarts if recycling section is mis-configured:

---

List of assemblies - Always

It easy to overwrite newer assembly version by building VS project into bin folder with Copy Local set for project reference assembly (f.e. project references CMS 7.2 Update 2 assemblies, but an upgrade to 7.2 Update 6 was performed yesterday).

You expect to have CMS 7.2 Update 6, whereas obsolete logic from Update 2 is actually used =\

---

Global.asax - Always

The main application class that directs ASP.NET processing, good to see expected value there.

F.e. Having class not based on Sitecore.Web.Application would result in no Analytics data is flushed, as SessionEnd pipeline is launched there.

---

Machine hardware info - Always

You want to ensure Sitecore is not launched on Pentium II :)

---

Windows Event logs - Always

Logs carry Sitecore shutdown reasons. More details in Why does site recycle or crash from IIS logs post.

---

IIS Logs - Not really

You can get different statistics on incoming requests via Microsoft IIS Log Parser with SQL-like.

Logs are usually massive, and ought be collected when a site slowness, or hack attempts were reported

---

Information about all sites in IIS - Not really

For performance-related issues only. You want to ensure single box does not host 100500 sites :)

---

File system permission - Not really

Only in case a setup is new, and Logs report a lack of file system permissions.

---

Copies of all assemblies in the /bin folder - Always

Each Sitecore solution has some amount of customization, it is important to review the code in nearby areas to ensure it is not the culprit.

---

Framework files - Not really

Only in case a memory snapshot was collected, and should be analysed on another machine

---

Upgrade history - Not really

Needed only in case you have performed an upgrade recently.

---

List of all files & hash codes - Always

Compare with a data collected from clean Sitecore solution to locate any file differences (f.e. JS, or CSS)

Any browser markup, or javascript error might be provoked by an obsolete file presence.