Symptoms

K2 host server stops unexpectedly at random time without any very clear pattern.
 

Diagnoses

In case you see the following exception in Event Viewer logs / or crash dump which originates from System_Transactions_ni!System.Transactions.TransactionScope.Dispose():

Entry point clr!Thread::intermediateThreadProc

This exception usually occurs when there is a call to some SmO which returns number of records higher than default buffer records setting for K2 host service (20,000). Service crash in this scenario related with use of TransactionScopes which we no longer use in 4.7. There are two possible solutions for this issue:

1) Increase buffer records value so that it can accommodate large set returned by SmO. Downside of using this workaround is that K2 host server will have to use more memory during huge SmO calls (specific number depends on how many columns and of which data type are returned by SmO) and essentially you don't know when you have to increase it again.

2) Preferably you have to isolate specific SmO call used in your environment which returns 20,000+ records and adjust it so that it returns small/filtered result set. Once this is done there is no need to increase buffer records value. With high probability this SmO call can be related with SharePoint SmO (huge lists/libraries in use + disabled/increased default SharePoint list thresholds are good indicators that this may be the case).
 

As a general rule in case you suspect dealing with similar issue try to increase default bufferrecords value from 20,000 to 100,000 and if it does not help to 200,000 (you need to get something higher than offending SmO call). In case after setting certain bufferrecords valure to some high value you no longer see service crash issue you should focus on specific SmO call somewhere in your solution which returns more that 20,00_ records but less than recently newly configured bufferrecords value.

Note that for example for SharePoint get list method even if you filter results when you do filtering using non indexed columns you essentially pull entire unfiltered list first - this operation will trigger SharePoint threshold as well as above desribed issue.

Resolution

Either try to isolate service crash to SmO list method which returns large data set (> 20,000 items) and apply filtering to this SmO call or increase bufferrecords setting to accomodate data set returned by SmO. As a permanent solution consider upgrading to 4.7 where this issue does not occur as TransactionScopes no longer used starting from this version.

If you see similar issue caused by SQL SmO call contact K2 support to obtain coldfix for K2 4.6.11 or consider upgrading to 4.7.  When it cames to SQL SmO service crash may happen when transaction was being closed by a thread handling buffered records on nested threads whereas the transaction needs to be closed by the thread which started the SQL transaction. The manner in which the SQL transactions are managed by ou K2 SmartObjects stack in 4.6.11 have been re-designed in the 4.7 release.