Problem with CPS Export

[TobiasFl]

Hello together,

i have a problem with the export of my project with CPS 5.8.4.

I just migrated the project from 4.11 to 5.8 and updated the STD folder.

After adjusting a view objects in the project i wanted to export it and i get the following errors:

Does somebody has any clue how i can start to find the problem?

Is there any guide what to check step by step to analyze the problem?

thanks for helping!

[Thorsten_Brach]

That looks strange...

What the problem is, the dialog shows - the access to the "Wzwiia0V.DLL" is denied - but I do not understand why this DLL is accessed ?
Are there any own developed objects or addons, in whose export / HMI-forms  this DLL is accessed ?
Or is there a pre-export or a post-export script that is executed ?

This DLL is nothing what comes from Nexeed and the DLL call must be something what is added in the project...

Have you ever searched the project files with a tool like AgentRansack, whether there is somewhere the DLL call to be found ?

If you take a closer look at the exception, then there is a reference to Bosch.OpCon.Engineering.ControlSystems.HmiSfcExport,
so that I assume that it must have something to do with the HMI export

...

[TobiasFl]

I have some AeMesAddons in this project but these are not using any DLL data.

The DLL error is always changing after every export try.

I also checked the project with AgentRansack but i dont find anything about this DLL. 

I also checked *.dll to find every DLL in the project but no one is looking like the DLL in the error message.

Is there anything else i can check to find some cause of this problem?

[Thorsten_Brach]

Do you use some custom or 3rd party HMI Controls ? Maybe the exception comes from a HMI control...
Or do you use specific template files in your STD folder ? Maybe there is something inside...

I would backup the project and then throw out addons and objects step by step until the exception disappears .
Then you know which object/addon caused the exception and you can take a closer look on it...

Alternatively,  you can send the project to the helpdesk and an expert can then debug into the export...

[nexidator]

All export script files are compiled into .NET assemblies at runtime. We are working with an option that should generate the modules in-memory, but it looks like the dlls are still written to the file system temporarily. The random assembly names are also generated by the .NET framework. So, nothing mysterious so far...

The important question is why the file cannot be accessed. We recently had a similar case where the reason was a visus scanner (Sophos Endpoint). If you are using the same virus scanner, you will need to work on its settings. (I do not know any further details.)