Video Screencast Help

Error when opening workflow projects: System.NullReferenceException

Created: 15 Aug 2012 • Updated: 29 Aug 2012 | 11 comments
This issue has been solved. See solution.

Hi, I'm getting this error whenever opening up any workflow projects of type .workflow, .webform, .decision, and .monitoring (can still open integrations). It also appears when trying to create new projects as well. This exception is also viewable in my C:\Program Files (x86)\Altiris\Workflow Designer\Logs\logicbase.toolcore.exe logs:

System.NullReferenceException: Object reference not set to an instance of an object.
   at LogicBase.Tool.MainForm..ctor()
   at LogicBase.Tool.Program.LaunchTool(String[] args)
   at LogicBase.Tool.ToolInitilizationHelper.Main(String[] args)

There isn't much to work with here. I've tried things like reseting the server extensions, which usually solves most of my troubleshooting issues, but that hasn't worked. I can't recall anything out of the ordinary that I did that may have caused this. No issues on Monday night, but ever since Tuesday morning, this issue has occurred. This is my local machine, by the way, so there are no other users, or any sort of server maintenance going on here.

Any ideas? Thanks.

Comments 11 CommentsJump to latest comment

chaotech's picture

Not sure it is the exact same issue, but I tried moving a workflow (decision project) from one server to another, checked it into the new repository, and now nobody can check it out. I moved the integration library that goes along with it the exact same way. It checked in and can be checked out fine. As soon as anyone tries checking out the decision project however, including the box that I originally built and checked in the project on, workflow manager crashes with a null reference error. An error shows up in the windows application log on the box trying to check out the project:

Could not register ProjectOpenRemoteObject type System.Runtime.Remoting.RemotingException: Failed to create an IPC Port: Access is denied.

On the SMP hosting the repository, an app log entry shows:

Source: /LM/W3SVC/1/ROOT/Altiris/Workflow-6-129895109569649240Unable read localserversetup.xml - Defaulting to true System.Exception: File not found: 'unable to get path'at LogicBase.Framework.utilities.SSLTrust.InitiateSSLTrust()

I'm using a common service account on all of the involved machines that has admin access across the board. I've been able to intermittently check out the project on a couple of machines, but for no apparent reason, it will stop working again. The error messages seem like they would be good clues, but i've not been able to find anything helpful.

Has anyone else seen this?

AnaMan's picture

Such exception can be thrown in different situations, for instance when the Designer is started it tries to locate where is stored the Server Extensions (Symantec Workflow service) configuration file (localserversetup.xml).

The seraching process is done by reading form windows registry - keys HKML\SOFTWARE\\LogicBase Server Extensions (on 32bit systems) or HKLM\Software\Wow6432Node\\LogicBase Server Extensions (on 64bit systems).

The default path for this file is C:\Program Files\Symantec\Workflow\Server Extensions.

Check if you have all these correct on machine you use for projects editing. And check also if user accounts you use have sufficient privileges to access registry branch and this config file.

bobbymc's picture

Today I tried to re-install Workflow Solution, and even do a full uninstall + install. Still getting the same issue as above.

And chaotech, I have seen that "Failed to create an IPC Port: Access is denied" error before, particularly on a shared server that the entire team uses. The affected project would be able to be opened for some users, but then another user would try opening that project and get this error.

Unfortunately, I haven't found a solution for it. The way it intermittently pops up and seemingly goes away after a while makes it hard to pinpoint a root cause.

AnaMan's picture


What version of Workflow have you installed?

Considering from stack trace you've attached when you try to run these older types of projects an older version then 7.1 SP2 of the Designer application is trying to start.

It seems that maybe you installed newer version of Symantec Workflow without fully uninstalling an older version. Newer version are using only single .SymWorkflow extension for all project files.

bobbymc's picture

Thanks for the response. I'm still on version 7.0, more specifically 7.0.1313.28. This has always been a constant.

chaotech's picture

 I found the problem (and solution) in my case. - My appologies bobbymc, if this is not related to what you are seeing; no intention of hijacking your post.

In my case, when I moved the project from the repository on one server to another, I first migrated the integration library, then the main workflow project. This step went without incident. Then, when I tried opening it from the new repository from any designer (almost), it would crash. The only designer I could ever get it to open on (intermittently) is the one on the server the workflow had previously been published to.

I noticed that when opened from the new repository, in the "Libraries" tab, the path listed to the .dll file of the integration library was still set to what it was in the old repository. Also, in the "Repository" tab, the library still appeared, but in the "Server" field, the old repository server was listed.

To remedy this, I added the same library from the new repository both in the libraries tab, and the repository tab, which then allowed me to remove the old one. Once I did that, I checked it back into the new repository, and have been able to open it on any designer I please. I suspect the only reason I was still able to open the project on the original server before I fixed it is that the path to the library was valid. On any other designer, that path was invalid, and caused a null reference.

Hope that is helpful to you...

bobbymc's picture

The issue seems to have "spread" from only my local machine at first, to a shared server we deploy projects to, and then to a 2nd shared server.

Again, this error only occurs when I'm logging on with my user account specifically. That fact, as well as the way it propogated across the servers might suggest an issue with Active Directory?

I've checked with the AD folks, and they weren't able to find any inconsistencies between my permissions / groups / etc and fellow coworkers who use the Workflow Solution.

The other common demoninator is that all three of these machines that I'm receiving this error on are connecting to the same Notification Server. But then again, everyone who uses Workflow here uses the same admin-level NS Server credentials, yet only I'm receiving this error.

chaotech's picture

So this occurs when you try opening a project from a repository, right? You might try removing and re-adding your AD account in the SMP account management. Perhaps something got corrupt there...

bobbymc's picture

Opening from our SVN repository, opening locally, or even creating new projects gets me this error.

I thought it might be an issue with how my account is interacting with the SMP, but I don't see any individual accounts anywhere in there, only the one shared admin account that everyone uses to connect their installation of workflow solution to the SMP.

reecardo's picture

What happens when you launch the ToolPreferences Editor (under Workflow Designer - Tools in the Start Menu)? Do you get a similar error or does that open?

There are a few things the tool used to do in 7.0 SP3... it fetches tool preferences, and based on some preferences (Save Diagram Window Layout), it tries to fix the layout. It could be there's a failure in fetching the preferences.

bobbymc's picture

Hi Reecardo. I'm still able to open the ToolPreferences Editor as well as all of the other tools in this folder.

edit: I started tinkering with some of the settings in here just now, and since you mentioned the Diagram Window Layout settings, I noticed that the two settings below were checked. Don't know why or how this became a problem just recently, but unchecking these allowed me to open up projects finally. Thank you!