This is a call to all my future friends in radio
You are the weight I need to keep me on the ground
No alarms – I feel okay -  counting cars to pass this day
I keep repeating all the feelings that I know
 
I like wolves in human clothes to hold me
Don’t look now there’re crazies at your door
Preaching love is bragging for the lonely
Rest your eyes there’s many miles to go
 
This a call to all queen mothers with their arms up
You are the lonely empire waiting for the fall
No alarms – you feel okay -  counting cars to pass this day
You keep repeating all the feelings that you know
 
I like wolves in human clothes to hold me
Don’t look now there’re crazies at your door
Preaching love is bragging for the lonely
Rest your eyes there’s many miles to go
 
Your name – I’m calling now – we’re so elastical
Your name – I’m calling now – we’re so elastical
Your name – I’m calling now – we’re so elastical
Your name – I’m calling now – we’re so elastical
 
We’re so elastical
This is a call to all my future friends in radio…

Copyright 2010 – Lovedrug / Street Talk Media

The following tool makes quick work of trying to find differences in the GAC for remote servers and evens offers up a nifty HTML report. Very nicely done.

http://gaccompare.codeplex.com/

A couple things – you need to have Admin rights on the remote computers, the tool does take a while to do the compare (so be patient) and to get the HTML report and other cool features, right-click in the results pane after it has loaded.

W3wp.exe is the worker process that Internet Information Services (IIS) uses for the application pools on your site. Each application pool, is assigned a separate worker process. That way an exception or crash in one of your application pools doesn’t affect other sites running in a different app pool.

To identify which w3wp process belongs to which application pool, here is what you will need to do. NOTE: this is specific for IIS 7.

In Task Manager, switch to the Processes tab. From the top menu, click on View and then Select Columns…, ensure that PID (Process Identifier) is checked.

Now open a command window (Start -> Run -> cmd.exe) and change directory to the following path,

cd c:\windows\system32\inetsrv

*notice that inetsrv may be inetsrv32 or inetsrv64 depending on your specific version of Windows Server.

Once in this directory, type the following:

appcmd list wp

The output will appear with the Process ID (PID from Task Manager) and the associated application pool belonging to it.

Another helpful command is: appcmd list requests

This will list all current requests and other useful information, such as time in milliseconds to help you identify long running requests.

The issue stems from the performance counters on the server being disabled. To verify – run the following at the command line,

lodctr /q:PerfProc

If you see the following,

[PerfProc] Performance Counters (Disabled)

The performance counters are not running. To activate them, run the following command,

lodctr /e:PerfProc

Once done, close any instances of the IIS Manager that you had open. Reopen IIS Manager, and you should now see the Worker Processes feature. Now only if the error message could have told you all that :-).

Thanks to the following for information about this issue:

http://bit.ly/b9yhrV

You can also click into the worker process and view the current requests that are being processed, including the current requested url, client ip, and the time elapsed for the request. Again, very helpful information.

To access this feature, click on Start and then the Run command. Type in inetmgr to launch the IIS Manager Console. In the left pane “Connections” click on your server. On the right pane, you’ll have the feature view. There’s a section called IIS, and one of the last icons should be labeled, “Worker Processes”. Double click, and it will display all the current worker processes. Double click on a process and you’ll see the current requests. You can repeatedly click “Show All” to refresh.

The WebDeleted.aspx page references the simple.master page which we redirect to our customized application master page. Apparently this results in the page trying to load in elements that are out of context for it. The solution was to stop redirecting simple.master and instead route it back to the SharePoint out of the box simple.master.

So with the three columns, the following CAML query can be used to query items that should be currently displayed:

SPListItem item = GetItemFromSomeWhere();

if (item.ParentList.BaseType == SPBaseType.DocumentLibrary)

{

// This item is from a document library – it probably contains a file.

}

1. Xbox 360 – countless hours of happiness!
2. C# – one of the most beautiful languages ever written for a computer.
3. ASP.NET – started out as a web framework with so much potential and it has never failed to deliver.
4. .NET Framework – an endless repository of win!
5. Windows 2000 – the perfection of an operating system – for its time.
6. Microsoft Excel – spreadsheets rock!
7. Active Directory – unlike any network directory service you’ll ever encounter.
8. LINQ – because I’ll never use a foreach loop to search through an object collection ever again.
9. Surface Computing - the single most *real* advancement for true ubiqtious computing beyond personal devices.
10. Zune HD – despite lacking phone capabilities – a marevelous piece of hardware with equally amazing software integration.

The underlying problem is caused by a poorly written function called GCComputeSizing within Core.js The common fix is to override this function by defining your own function called GCComputeSizing in a script reference that is loaded in after the reference to Core.js is called in your master page.

However, what most of the other blogs and resources fail to mention is that Core,js can sometimes be loaded in using the “defer” attribute of the script tag. When this happens, core.js will now be loaded in after the page is loaded. Unless you also defer your override script, you will invoke the built-in GCComputeSizing function and the bug will persist.

This problem was specifically noticed when using user-defined or custom datasheet views. Comparing the source html for standard and custom datasheet view yieled the following:

Standard Datasheet View:
<script type=”text/javascript” language=”javascript” src=”/_layouts/1033/core.js”></script>

Custom Datasheet View:
<script type=”text/javascript” language=”javascript” src=”/_layouts/1033/core.js” defer></script>

As you can see, only custom datasheet views were loading in core.js  as a deferred script. Adding the defer attribute to our custom override script fixed this problem by deferring the override after the deferred core.js was loaded.

In terms of overriding GCComputeSizing  there are many examples easily searchable through the interwebs. One word of caution though, as a person who has quite a bit of experience with Javascript, GCComputeSizing not a function suitable for production. Even some of the *corrected* versions that others have posted still make me uneasy. Anything that has the potential of throwing a client’s browser into an infinite loop and locking up their cpu is a serious  cause for concern. Fortunately, our customized design uses a fixed layout so I was able to simplify GCComputeSizing to the following:

function GCComputeSizing(GCObject)
{
    if (TestGCObject(GCObject))
    {
      var lGCWindowWidth=663;
      var lGCWindowHeight=550;

      glGCObjectWidth = lGCWindowWidth;
      glGCObjectHeight = lGCWindowHeight
    }
}