6.1 backend config issues

I recently upgraded my site from 5.0>>5.2>>5.4>>6.1 as outlined in the published upgrade path.
Currently in 6.1.4600.0.
In the backend pages I have some filters in various Content areas that do not function properly. For example when a filter is selected I get a website page on the front end.
Based on other posts here I suspect that some of the site config files did not update properly and I may have persisted values in some config files from one of the intermediate upgrades or even the original 5.0 config files.
The standard Empty Project nor the Sitefinity SDK do not include copies of the default versions of these files for the release build.
Are there default versions of these files buried away somewhere?

CadPilot,

Unfortunately there are no default .config files stored anywhere.  However, Sitefinity will assume the default values if no config file is provided.  So my recommended approach would be to remove any .config files that you suspect are having issues and perform an IISRESET on the web server.  Sitefinity will then assume the default settings and you will then need to update these settings again.  Before you do this make a back up of your web files and the database.

If that does not work then I would suggest creating a new instance of Sitefinity and comparing those config files to yours.  I use a comparison tool called Beyond Compare 3 just for situations like this one.  Hopefully this will be helpful for you.

Craig

Thanks Craig.
Its the answer I more than expected but one can hope.
Depending on the module and the release build I've had mixed results doing what you suggest.
I choose to avoid pain if possible.
It is more than annoying to have to build a sample site for no purpose other than this.
That is not as annoying as still no sitemap.xml generator module out of a state-of-the-art CMS :)
I'm old school I guess. I still rely on Notepad2 for stare and compare. Thx for the other tip.
I'll leave this thread open and unanswered.
Maybe someone in SF support will think to put them somewhere to avoid chasing rabbit trails elsewhere :( 

@CadPilot,

I'm not Telerik support but as far as I'm aware Craig's solution or comparing .config files from a blank/fresh solution is the only way because config files are littered with project based guids.

They do keep a 'copy' in the database, but naturally they'll contain your same flaws...

If you're unsure if its your tweaks or upgrade failures that cause the .config chaos, best to start with opening your SystemConfig.Config and remove all version="x.x.x.x" from the <applicationModules> and restart your site. Also verify that they're not are set to 'disabled' prior to upgrading or they won't get updated.

P.S.
sourceforge.net/.../download :)

Jochern,
See your posts a lot. Always helpful.
Thanks for the tip about the disabled app modules. Should have thought of that. Arrrrgh
That little tidbit should go into the Update checklist documentation.
I run on the hosting provider arvixe which fine once the site is running for a bit. But I don't have any real control of the app pool.
I've found it works best to disable down to a min number of modules for SF and turn them on after the site reloads and runs for a bit. The hosting provider's app pools seem to prefer to grow up to Sf's often noted piggishness :).
Since I bounced through a number of release builds getting to 6.1 I'm sure I missed the disabled mod issue here and there.
Still despicable from my perspective SF won't simply take a few minutes before release and supply a copy of the raw config files for a build.
A copy of the known good would save lots of people TIME.
I see related ripples of this issue all over the forums.
As you suggest I'll scrub my SystemConfig.config on my dev server and see where that takes me.
I will still await a telerik response and leave the thread open.
I'd toss in a ticket...but that won't solve the problem for others.
Thx