When the process is re-run, do they actually re-use the password? It seems to be randomly generated. Perhaps it doesn't work on the other side in some situations. Have you tried monitoring network traffic or adding some logging in the microflow to see if the password field is really filled even for the cases where it fails? Or does the error that you pasted with 'Er is een fout opgetreden' come directly from your microflow logging?
Looking at the code this can only happen if the password being set is null, there's no real way around it. You can check the code of this open-source project for the specific version we're using at http://vt-middleware.googlecode.com/svn/vt-password/tags/vt-password-3.1.1/src/main/java/edu/vt/middleware/password/Password.java (check line 66 which it mentions in your stack trace). Now I know we're not emptying the string before setting it so it must come in as being null already.
This error occured with an app I'm working on in the following situation:
A System.User derived entity (webserviceuser) with an additional attribute (integer).
In the create action of the webserviceuser, the password is set, and the integer is set by copying an attribute (long) from a different object.
Whenever the long exceeds the max value of an integer, instead of returning the expected,
‘Object id: 42502721483315464, validation errors: (member: integer, message: De opgegeven waarde moet kleiner zijn dan 2147483648)’,
the Password.class file generates an unhandled error on line 66 where it tries to get the length of a null string.
So when this error occurs, check if any other attributes are set where the member types are mismatched.