Value cannot be null. Parameter name: s

  • 22 September 2014
  • 22 replies
  • 11 views

Badge +3

I have 10 list items in a SharePoint 2013 list and there are 3 workflows associated with the content type of those list items. All 3 of them have a conditional start for new created items, based on the value of a column.

 

When monitoring the ULS, I find 163 identical errors. All of them are like this:

 

09/22/2014 16:10:16.90 OWSTIMER.EXE (0x2B20) 0x05A0 Nintex Workflow 2013 General 00000 Unexpected Error processing item updated event.: System.ArgumentNullException: Value cannot be null.  Parameter name: s     at System.IO.StringReader..ctor(String s)     at Nintex.Workflow.PreviousValueRecordCollection.nxk=(String oBk=)     at Nintex.Workflow.ConditionalWorkflowStartReceiver.kBk=(SPItemEventProperties kRk=, AutoStartRuleType khk=, Boolean kxk=)     at Nintex.Workflow.ConditionalWorkflowStartReceiver.ItemUpdated(SPItemEventProperties properties) (Build:3080) f7fdba9c-8e28-c0b5-dbb7-a7a8cf1862d5

 

The workflows don't appear to be suffering from this since they just run fine. But I'm interested to know what these errors are about and if they can be avoided.

 

Thanks,

Bart


22 replies

Badge +11

Did you create this variable name 's' anywhere? I'd be curious to see what happens if you shut off all the workflows and create a new item in the list to see if the error occurs again. You need to isolate the problem so you can see where it is coming from before you can fix it. If there is no error with no workflows running, then turn one workflow on at a time as you create an item checking for the error to see what workflow could be causing the problem. It is like a string value is null but at least may need to be set to empty or there needs to be a check for null on that string and something else done if it is null.

Badge +11

Another troubleshooting trick to try is to write to the workflow history log throughout your workflow to see if the error time corresponds close to one of your workflow actions.

Userlevel 7
Badge +17

The 's' that is null is the string parameter to the system.io.stringreader which is being called within Nintex.Workflow.PreviousValueRecordCollection to fetch a string value and it can't because it is null. This is new to 2013 as it is not in the 2010 SDK and I do not believe the 2013 SDK is available to reference. The workflow is starting up correctly, but then a value needs to be compared and it cannot. This could be anything with this much information, from a bad xml configuration, to a misconfiguration in the workflow.

Do you have any default values for variables? what is the condition for the start? what is the first action in the workflow? In the history, do you see it getting past the first action(It doesn't seem to)? Are all values in the item valid?

Badge +3

Already thanks for the insights.... to answer a few of the questions:

- I don't use any variable or parameter with the name 's'.

- The start condition is when a field "Blocking Scenario" equals "Q" (for new items only). Updated items are not handled

- The first action is the workflow is actually a parallel action block with 2 branches: Branch 1 calculates a variable "CurrentDateTime" to the current date and time while Branch 2 immediately has a "Wait for Item Update" action which waits until a field "Scenario" is set to "D" (choice field). Initially, this field is "N".

- The workflow actually runs perfectly. I can see it running through all actions in the history. But when monitoring the ULS, I see multiple errors popping up.

Now, I did found something regarding the Wait for Item Update action in combination with a Choice field. Look at this post:

https://community.nintex.com/message/3512#3512

Can this be related?

Badge +11

Is the "Blocking Scenario" field required? If not, it could be coming in as null and possibly causing problems. Fat chance but check it out.

Userlevel 7
Badge +17

Sometimes I have had issues with some conditions being tested as the first action and setting a pause for a minute seems to always help out. But there is no requirement to add a pause as the first action. Sometimes it just let's the timing of actions to calm down before the real work get's going.

Badge +3

Nop, it's not required but I'm adding items via PowerShell to the list and it's always filled in. It also has a default value when new items are added.

Badge +2

Hi All,

I'm getting a similar error (see below) on 2010.

The message mentions "PreviousValueRecordCollection" and "ConditionalWorkflowStartReceiver" even though this workflow has no conditions on starting (it is started automatically on item creation, or manually, possibly via a button on the item menu).

The error seems to come from an update to the current item, although the Workflow Progress page shows this having completed, and the workflow progressed to another action where a variable is set based on a different field in the current item.

Any ideas what would cause this problem?

Thanks,

Mark

This is the error message in the log. It appears 7 times for the same workflow.

w3wp.exe (0x1A2C)                        0x2BB8 Nintex Workflow 2010           General                        0000 Unexpected Error processing item updated event.: System.ArgumentNullException: Value cannot be null.  Parameter name: s     at System.IO.StringReader..ctor(String s)     at Nintex.Workflow.PreviousValueRecordCollection.zhk=(String zxk=)     at Nintex.Workflow.ConditionalWorkflowStartReceiver.oRY=(SPItemEventProperties wBk=, AutoStartRuleType wRk=, Boolean whk=)     at Nintex.Workflow.ConditionalWorkflowStartReceiver.ItemUpdated(SPItemEventProperties properties) (Build:23140)

Userlevel 7
Badge +17

Though this has a similar message with the parameter name s error from System.IO.StringReader, it is most likely not a similar issue in your case. I'd suggest starting a new post and provide some more information around the update item actions you refer to.

Also, you could Follow this post for anything we may discover down the road in this discussion.

Userlevel 7
Badge +17

I love that you like PowerShell, it's the best tool an admin could have. I think we had another discussion on its use. Are they related? You are not doing system.update() correct? Are you using RunWithElevatedPrivileges? Are you updating the item from the context of that site? Sometime a AllUnsafeupdates needs to be enabled, but that may not be in play here.

I want to think that there is no issue with using PowerShell to create items and for workflows to start. In my applications I create list items via code on the server side and the workflows start as expected. Also, in some situations, I have applications create an item and also manually start a workflow based on a condition in the code. So the workflow starts on demand, not auto, and no conditions within.

Badge +3

PowerShell is basically the only interface I use to manage SharePoint. But that said... I do have another discussion going on the use of PowerShell together with the "Wait for Item Update" action not detecting the change. I don't know if this is somehow related. The issue I'm discussing there is actually completely blocking the flow of the workflow and basically all workarounds fail, while this error pops up multiple times in the ULS but doesn't do anything to the flow or the execution of actions. So, I'm somewhat confused on the "why" of this error. Regarding your questions:

- I was doing a SystemUpdate($False) but changed this to Update() to make sure all updates are regular updates.

- RunWithElevatedPriviliges... I don't use this in PowerShell. The script is executed as the Admin user.

Workflows do start without issues when items are added through PowerShell. No issues there.

But I have been in contact with support for my "Wait for Item Update" issue and they reviewed my workflow and recommended to add a 1 minute wait action as the first action in my workflow. We are in progress of doing this now and see if it's related.

Userlevel 7
Badge +17

Good info. And I agree, More admins should be using PowerShell everyday. I just find that most do not know how to use it.

The Wait for Item Update does require a SharePoint commit to evaluate effectively, so a pause can help there. But what I was going to test later, and maybe you can tell me, does the Wait for Item Update "ADD" an event receiver to the list item? I assume it does not. Therefore, if it evaluated on a commit it should still be evaluated in the w3wp process. That is, until a Pause is added. Then it will be evaluated in the OWSTimer.  But either one, without an event receiver in play, updating the item with PowerShell should have no recourse.

Badge +3

Each list you creae has 3 event receivers by default:

- "Nintex conditional workflow start" with the type ItemUpdating

- "Nintex conditional workflow start" with the type ItemAdded

- "Nintex conditional workflow start" with the type ItemUpdated

I created a new workflow, added a Wait for Item update but no extra event receivers are created. For me, it seems like everthing is handled in the 3 default eventhandlers.

But this is where I'm getting a little bit worried...

The list where we are working on has 9 (!!!) eventhandlers. 3 ItemUpdating, 3 ItemAdded and 3 ItemUpdated. I'm wondering why. I created a new list where I did nearly the same. It had 3 eventreceivers when I created it. I added 2 workflows with a conditional start and both have a wait for item update action.

When instantiated and "In progress", I still have 3 eventreceivers.

I'm starting to wonder if this is the core of all my issues I have. It is possible to remove those eventreceivers in some "supported" way? I could go in using PowerShell and start to beat the life out of those eventreceivers but I don't want to make matters worse.

Badge +3

OK... getting complicated. happy.png

Got word from Support that this might indeed be problematic and they proposed that I just delete the duplicates using PowerShell or SharePoint Manager. I did this but when I started testing again, I noticed that suddenly I had 6 instead of 3 event receivers.

Before deleting the duplicates, I did some more inspection with SharePoint Manager and I noticed that each eventreceiver has a "Data" property which has a specific value (numeric). What I noticed was that each "set" of 3 eventreceivers (ItemUpdating, ItemUpdated, ItemAdded) had the same value for that property.

Now, when I deleted the duplicates, I didn't pay attention to that value.

So, it might be that the 3 unique occurences I retained, were not of the same “set”. I don’t know for sure, but chances are slim that I managed to single out the correct ones by accident. happy.png

So, I’m left with the following (the values below represent the Data property values):

ItemAdded        ItemUpdated    ItemUpdating
1                             1                             3

It might be (I’m checking this with Nintex Support) that in my case the sets are “incomplete” because:
Set 1 => Missing the ItemUpdating eventreceiver
Set 3 => Missing the ItemAdded and ItemUpdated eventreceiver

And that the system regenerates the missing eventreceivers in this case to have a complete set again, resulting in:

ItemAdded        ItemUpdated    ItemUpdating
1                             1                             3
3                             3                             1

=> 6 eventreceivers or 2 complete sets.

The reason why I’m thinking in this direction is because when I removed the duplicates again when I had 6 eventreceivers, I DID pay attention to those Data values and made sure that the occurences which I retained, all had the same “Data” property.
And now, I only have 3! No new occurences are created.

Anyone with more insights on this?

Userlevel 7
Badge +17

I'm not sure what the data values are for as for the other list with two workflows did not duplicate the event receivers. So it would not be to mark an instance ID or anything.

I was going to mention to manage using SharePoint Manager, but PowerShell rules!

You've provided some great information for me that I am interested in. It is a good troubleshooting step to review this in the future. But I believe that this would not be the case for the general public to perform this level troubleshooting and should rather contact support.

So what are your results now? You have 3 handlers, but what happens on the Wait? Does the workflow behave?

Badge +3

For the moment it's purring like a kitten, resuming immediately when the condition is met (with or without PowerShell) but this was already the case since we started using a checkbox in our wait condition instead of a choice field. The real issue was (yesterday) still occuring on long-running workflows which are waiting for over 2 days or so. When the condition to proceed was met after 2 days, it didn't continue anymore. So, to know if everything is working as expected... I have to wait until monday. Then I can change some values and see if the workflows resume.

So, I will return with the results on monday.

Concerning the eventreceivers... I have 64 (!!!) WorkflowCompleted eventreceivers on the web level with the name "Created By Nintex Workflow Start Action". confused.png Doesn't seem right, does it? But I don't know where these are coming from. I have 1 site workflow. That's it.

Badge +3

happy.png The issue with the Waiting for Item Update has been solved! Some things we did:

- include a pause for 1min at the very beginning of the workflow as first action.

- Cleaned up the event receivers on the list

Long-running workflows are now resuming without issues after a value is changed, even if this is not done directly using the UI of SharePoint.

We still see those errors concerning parameter 's' popping up in the ULS multiple times but it doesn't affect the flow or functionality of the workflow at all. So, I'm going to ignore this for now since we have lost already too much time on these kind of things and we really need to get this thing going again.

Userlevel 7
Badge +17

Awesome, well done!

I'm trying to look back through the sequence of events. I'm wondering if the Pause was an absolute necessity or not. I know the event receiver cleanup was.

Badge +3

The pause, I'm not sure of this actually helped but it solved some other things we were experiencing... We saw 2 strange things when a workflow started (without the pause).

- When we looked at the history, we noticed that some actions were executed multiple times in the beginning.

- When we disabled "Safe Looping", we noticed that the workflow would create tasks multiple times. However, when you clicked any of these tasks, you would get a SharePoint error and a correlation ID which basically said that the object didn't existed. Only the last instance of the task worked. Weird stuff...

Once we added the stuff, these things disappeared.

Badge +3

Yes, I ignored them because I didn't find any negative impact from them in the actual flow. It just works as it was designed. Perhaps a false warning? It wouldn't be the first one with SharePoint. happy.png

Badge +1

Hi Bart,

What is the benefit of "Wait for Item Update" compared to writing a workflow that is triggered by an item update?

My background is document management software with workflows where it is adviced to write short running workflows that store their state in a parameter and stop till they get triggered again instead of one long running workflow that may get lost when the system needs a reset.

Userlevel 7
Badge +17

Gunnar,

This can depend on a lot of things. But most cases a Wait for Item Update action in a workflow is to allow a means to continue a greater process that needs a certain value. As you mentioned, creating shorter, sprint style workflows have its own benefit, but sometimes you are unable to start a new process after a modification to the item and the context of the longer running workflow at the time is very important to the process.

So the action has its place, but isn't the only way to trigger further processing on modification. All methods should be evaluated.

Paused workflows like these are stored in the content database too, so a system reboot would not harm them from finishing.

Reply