Troubleshooting anything to do with K2 Blackpoint the 1st port of call is going through your error logs:

All logging configuration (excluding SmartObject logging) is done through the following file:

C:\Program Files\K2 blackpearl\Host Server\Bin\HostServerLogging.config

When you open the file in notepad, or any other text editor, you will see a section that looks like the following:

<br /> <ApplicationLevelLogSettings><br /> <ApplicationLevelLogSetting Scope="Default"><br /> <LogLocationSettings><br /> <LogLocation Name="ConsoleExtension" Active="True" LogLevel="Info" /><br /> <LogLocation Name="FileExtension" Active="False" LogLevel="All" /><br /> <LogLocation Name="EventLogExtension" Active="False" LogLevel="Debug" /><br /> <LogLocation Name="ArchiveExtension" Active="False" LogLevel="Debug" /><br /> <LogLocation Name="MSMQExtension" Active="False" LogLevel="Debug" /><br /> </LogLocationSettings><br /> </ApplicationLevelLogSetting><br /> </ApplicationLevelLogSettings><br />

This section is where you can configure the various logging destinations as well as the verbosity. The default settings have only the Console destination active but you can turn on the other destinations by changing the Active property from False to True. The LogLevel property specifies the verbosity. The options are, from most verbose to least verbose, All, Debug, Info, and Error. My preference in a development environment is typically for Debug or Info as they give you enough information to be useful but not too much that you get lost. Error will only show you the errors which can be nice however usually some context is helpful. In a production environment however any log level above Error for any destination is probably overkill unless you are actively troubleshooting.

I also preference File logging as this creates a transmittable text file in the C:\Program Files\K2 blackpoint\Host Server\Bin\ directory.

Here is a brief description of the various logging destinations:

•ConsoleExtension – directs messages to the server console window. In a production environment where you are running as a service and have no need for the console output I recommend turning the console extension off as it will improve performance slightly.

•FileExtension – allows you to direct logging to text files. The App settings section in the config file even allows you to specify max file size or file durations.

•EventLogExtension – allows you to direct logging to the Windows Event Log. I typically recommend setting this to Error so that you don’t bloat your event log with standard info or debug messages.

•ArchiveExtension – allows you to use a SQL database as a repository for logging information. This is handy when you have a load balanced environment and don’t want to have to check each server’s log files individually. You can have all the servers in the NLB logging to the same database.

•MSMQExtension – allows you to log messages to the Microsoft Message Queuing system which other applications or services could monitor.

Once you have made the changes you want in the config file save your changes (you might also want to create a backup of this file just in case) and then restart the K2 blackpoint service. The new logging changes will now be in effect.

You may be overwhelmed the first time you open a text log file as there is a lot of information that is captured and browsing the log file in notepad can be daunting. What you will notice however is that the log file is comma delimited meaning that you can easily open this file in a spreadsheet application like Microsoft Excel. This gives you a way to do filtering as well as play with column width to enhance readability.

If you need more information on the logging framework there is an article here: http://kb.k2workflow.com/articles/kb000309.aspx

Source: k2underground.com