Troubleshooting
Problem
User launches the Controller client via a web link. * For example (if using Controller 10.1) user launches shortcut to http://controllersvr/ibmcognos/controllerbin/ccr.exe * Alternatively selects the Controller link on the "Cognos Connection" website's welcome page. However, the Controller client does not start. Instead, user receives an error message. NOTE: The Controller client works OK if the user has the 'local' (non-web) client installed. * In other words, it works OK if they have the CCRLocalClient.MSI version of the client installed.
Symptom
Screen:
- System.NullReferenceException: Object reference not set to an instance of an object.
at Cognos.Controller.AppContext.InitConfig()
There are no errors recorded in the Event Viewer.
Cause
The client device (for example, the end user's client PC, or the Citrix/Terminal Server from where they run Controller) could not download the .NET Framework run-time (client) code files from the Controller website.
There are several potential causes for this:
- Scenario #1 - Client device has a proxy server configured to act between the client device and the Controller website. The proxy server is blocking the code download.
- Scenario #2 - Client device's .NET Framework cannot perform a certificate check (of the IBM Cognos-certified .NET certificate) over the internet. Therefore, it will not allow the download of .NET code
- Scenario #3 - Client device does not have a .NET Framework trust configured, to say that it allows code from the Controller website to run on the client machine
- Scenario #4 - The website's .NET webuser (ASP.NET Machine Account = 'ASPNET') does not have sufficient NTFS rights to read the files inside the controllerbin virtual directory's parent folder (...\c8\webcontent)
- Scenario #5 - Webserver's ASP.NET has not been installed correctly. Typically this is because Microsoft IIS (the webserver) component was installed after Microsoft .NET Framework was installed
- Scenario #6 - It is a distributed installation (several Controller application servers), and the administrator forgot to install the '.NET client files' component onto the client distribution server. In other words, the virtual directory 'controllerbin' (which equates to the Windows explorer folder ...c8\webcontent\ccr) contained no client files (.DLL files etc.
- Scenario #7 - A 3rd party software component (for example a software firewall, or anti-virus product) is stopping the .NET client from downloading from the website (or running on the client device)
- Scenario #8 - Webserver's ASP.NET is not registered/configured correctly. For example, the ASP.NET configured identity does not have sufficient security permissions on the webserver
- Scenario #9 - I.T. administrator has forgotten to edit the file "applicationHost.config". This means that (by default) downloading .config files is blocked by the IIS webserver.
- See separate IBM Technote #1455096 for more details.
Diagnosing The Problem
You may need to investigate multiple scenarios before locating the one that solves the problem in your environment.
By launching the Controller diagnostic website (see below) you may get an error message that more easily helps you decide which scenario is applicable for your problem:
- http://<servername>/ibmcognos/controllerserver/ccrws.asmx
In addition, the following website may also give you a clue as to where the problem comes from:
TIP: The above web locations are the default locations for Controller 10.x.
- If your system is customised (or based on Controller 8.x) you will have to modify them accordingly.
Resolving The Problem
TIP: Before continuing, it is vital to check what the value of "CASUrl" is on your Client Distribution Server (see below):
In the above screen, the value is: http://COL43-5414-2609/ibmcognos/controllerbin
- It is *vital* that you use the same server-naming convention (in the above case it is the 'NetBIOS' name, not the FQDN) when you troubleshoot.
- TIP: As an example, a FQDN name would be something like http://COL43-5414-2609.mycompany.com/ibmcognos/controllerbin
Scenario #1 - Reconfigure the client device's Internet Explorer settings, to bypass the proxy server (between the client PC and the Controller web/application server)
- For steps on how to do this, see separate IBM Technote #1655498.
Scenario #2 - Allow client device to reach the internet, or reconfigure its .NET Framework client to disable Internet certificate checking
Steps:
Either
(a) ensure that the end user had an Internet connection
or (b) disable certificate checking by unticking (disabling) the box "Check for publisher's certificate revocation" inside Internet Explorer's Internet Options:
Scenario #3 - Ensure that correct version of .NET Framework is installed and configure it to trust the Controller 'Client Distribution Server' website
Steps:
- Logon to the client device (e.g. end user's PC) as a Windows administrator
- Check that the device has got .NET Framework client 2.0 SP2 (32-bit) installed, which is typically installed via the file "NetFx20SP2_x86.exe".
- Configure it to have a 'Full Trust' for the Controller website URL, by launching a Command Prompt and running a script similar to the following (modifying so that 'servername' is the name of the server *exactly* as written inside the 'Client Distribution Server' website):
cd %windir%\Microsoft.NET\Framework\v2.0.50727
caspol -q -m -ag "All_Code" -url http://servername/* FullTrust -name "Controller_servername" -d "Controller_mydescription"
Steps:
- Logon to webserver as an administrator
- Using Windows Explorer, browse to "webcontent" folder (TIP: By default, for Controller 10.1.1 on 64-bit Windows this is C:\Program Files (x86)\ibm\Cognos\c10\webcontent)
- Right-click on 'webcontent' and choose 'properties'
- Click on tab 'security'
- Add the local user 'ASPNET' to have 'full control' permissions, and click OK
Scenario #5 - Re-install .NET Framework on the webserver, and (when prompted) perform a 'repair' installation
Steps:
See separate Technote #1347370.
Scenario #6 - Install the '.NET client files' component onto the client distribution server
Scenario #7 - Temporarily disable third party firewall/VPN/web-caching/anti-virus software, to discover which one is causing the problem.
Scenario #8 - Webserver's ASP.NET is not registered/configured correctly. For example, the ASP.NET configured identity does not have sufficient security permissions on the webserver.
Steps:
See separate IBM Technote #1386247.
Scenario #9
On the Windows 2008 webserver, edit the file "applicationHost.config" so that downloading .config files is allowed by IIS.
- See separate IBM Technotes #1455096 & 1449854.
Related Information
1347832 - Configure Controller client to allow .NET 2.0
1347370 - An error occurred while trying to access the
1346159 - Object reference not set to an instance of an
1386247 - Error 'System.NullReferenceException: Object
1455096 - Error 'System.NullReferenceException: Object
Historical Number
1041517
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21367356