5 Replies Latest reply on Sep 23, 2014 8:29 AM by Curtis Watson

    SldWorks Object Instantiation on IIS Web Service

    Curtis Watson

      Hey there,

       

      We are having some troubles with some custom software we have wrote which interfaces with the SolidWorks API.

       

      Project overview:

      • Use EPDM to search for a part file, retrieve its bill of materials.
      • Use SolidWorks to open each file and export it to a PDF, stored on the company's local network.

       

      During development, a local IIS service was used on the development workstation. Thus, during development and debugging the developer could see the SolidWorks instance opening and the drawings being loaded as the service executed. I wanted to highlight this as I feel it is the main difference between the development and production environments. In the production environment, the service is running on an IIS server which is not logged in under a user account. Let me note that during development, no issues were encountered and the service executed perfectly.

       

      Now that we are done with development, we went to distribute the service to the IIS server... this is where we hit problems. The software can consume the EPDM API without issue and successfully find parts and retrieve their bill of material. The issue comes when we go to deal with SolidWorks. There is significant logging in our software and we have pin-pointed the failure to a single line where we instantiate the SolidWorks application:

       

      Dim sw As SldWorks = New SldWorks

       

      The above line will hang for approximately a minute before an exception is thrown. The exception thrown is as follows:

      Retrieving the COM class factory for component with CLSID {0D825E02-9000-4D82-B4AB-D6BDC2872797} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

       

      From my reading, it sounds that this is a general error and I should look into the server's event log for further details. I did so and found a different message, however not too much more description... just communicates that a general timeout has occurred for some reason:

      The server {0D825E02-9000-4D82-B4AB-D6BDC2872797} did not register with DCOM within the required timeout.

       

      I have confirmed that the API is operational on the production server. I accomplished this by writing a simple command line application that instantiated a SldWorks object and set Visible = 'True'. When executing this while logged into the server, SolidWorks opens successfully. It is only when it is running under the service account or under a non-logged in user that the issue is encountered.

       

      Also, all servers are located on-site, so there are no limitations by third parties, etc. The production server is running Windows Server 2012 with Microsoft IIS 8.0. SolidWorks 2013 and 2014 is installed, but from the CLSID of the COM error, it is trying to launch SW2013 - this is what we want.

       

      I have spent about a day researching this issue and have read the following items and attempted their respective fixes, without success:

      • DCOM security privileges - it was mentioned that the user account IIS is using to run the service does not have access privileges to the DCOM objects. I went into Component Services->My Computer and modified both the global default security as well as the individual DCOM object's security. I have additionally tried running the IIS service under different user accounts (<DOMAIN>\Administrator, <MACHINE>\Administrator, ApplicationPoolIdentity, NetworkService), each time ensuring the respective account had correct DCOM privileges, all without success.
        1.png

      • COM internet services - I had read that it could be related to COM internet services (found this one when searching more broadly). As such I tested this by enabling COM internet services. Still had no success.
        2.png
      • Allow service account to interact with desktop - I read that allowing the IIS service to interact with desktop could resolve my problem. As such I went to the IIS service Log On properties and allowed it to interact with desktop; still no success.
        3.png
      • Load user profile - I read that SolidWorks requires a user profile to exist for it to launch correctly. As such, I went to the service application pool's settings and enabled Load User Profile.
        4.png

      Any assistance is greatly appreciated.

       

      Edit 02/24/2014 #1:

      I have additionally tried the following solution without success:

      http://kb.monitorware.com/event-10010-server-did-not-register-t390.html

       

      Message was edited by: Curtis Watson

       

      Edit 02/24/2014 #2:

      I am trying to narrow the scope of the problem... I went into the component services and modified the security for SldWorks 2013 Application - I set the authentication level to None to try and remove DCOM security from one of the possible causes. After setting the security to None I still receive the same issue.

      5.png

       

      Message was edited by: Curtis Watson

       

      Edit 02/24/2014 #3:

      A little more information... I've discovered that the SLDWORKS.exe process is actually being executed for the duration of time that the service hangs on the SldWorks object instantiation. After the DCOM timeout period elapses and the exeception is thrown, this SLDWORKS.exe process then ends. Thanks again to anyone that can provide some guidance or troubleshooting ideas that I haven't yet tried.

      6.png

       

      Message was edited by: Curtis Watson

        • Re: SldWorks Object Instantiation on IIS Web Service
          Artem Taturevych

          Can you try to initiate SolidWorks from a stand-alone UI-less application like console one? Can you use ePDM Task instead of your custom service? The ePDM task is already has all this set up and because you are working with ePDM it will be much easier to redirect the execution to a server rather than writing your own service.

            • Re: SldWorks Object Instantiation on IIS Web Service
              Curtis Watson

              Thanks for the reply Artem. As I mentioned I had confirmed the functionality of the API on the production server through means of a console application.

               

              We explored the built-in EPDM task, however this solution was not sufficient for our requirements. We're essentially creating "drawing packages" for different departments. With our company's ERP system being developed internally, we were able to utilize this service directly within our ERP system; this allows us to utilize data within our ERP system in combination with EPDM data to achieve the results we want. We would be unable to achieve this with EPDM alone, without the data from our ERP system - for example, we can take an order, retrieve the BOM from both the ERP and EPDM system and print out an entire drawing package based off of the order within ERP.

               

              On a side note, I believe to have made some headway with this problem. Once I test and confirm the solution, I will post a reply to this thread noting the steps needed to successfully host SolidWorks under a WCF service. I have spent numerous hours searching and troubleshooting this issue, without finding much guidance on the web. Hopefully I can provide some insight into the actual steps required to launch a set up like this.

            • Re: SldWorks Object Instantiation on IIS Web Service
              Jacob Cordingley

              I went throught this too.

              It work durring devlopment and the it stop when on client

              Using SwDocumentMgr.dll in asp get COM error I found a  post i did years ago for the swDocumentmgr API

               

               

              It might be to old  I don't see that option  on windows 2008 server iis7 so it looks like they did some changes but this might give a new light on things

                • Re: SldWorks Object Instantiation on IIS Web Service
                  Curtis Watson

                  Thanks for the reply Jacob, that is one thread I had not found in prior research.

                   

                  I have a feeling our issues are similar but different. In IIS 7, they dropped the IIS Out-Of-ProcessPool COM object and all applications run out-of-process in their own application pools. There is no COM object for us to register our DLL's against.

                   

                  7.png

                  I have more-or-less resolved the issue. I needed to configure the DCOM object's identity to launch under an interactive user... there is however side effects to this as we have no control over which interactive user profile SolidWorks is opened under; or if no interactive user is logged in, the DCOM object likely will not launch (I have not tested this).

                   

                  After we decide our final implementation plan, I will write up a guide detailing the configurations and steps needed to configure this correctly.

                   

                  Thanks for the help everyone!

                • Re: SldWorks Object Instantiation on IIS Web Service
                  Curtis Watson

                  Been a while since I last looked at this post - realized I had not posted the resolution. Hopefully others can find this useful.

                   

                  Essentially SolidWorks requires an INTERACTIVE user session to exist on the station running the web services. I was not able to find a way to accomplish this through DCOM settings unfortunately. It would be great if SolidWorks provided a service, which had permissions to interact with the desktop - we'd be able to let SW run under its own desktop heap when a service call is made against it. Anyways...

                   

                  To solve the problem, you need to get that interactive session logged into the server. You could simply have a user (or administrator) log into the server every morning and disconnect, leaving the session active. This is not automated and is to say the least, unideal. My solution is more so a workaround for the problem, but provides an automated means of logging in a user.

                   

                  First, create a RDP file that will connect to localhost using some account; you must save the credentials.

                   

                  Second, create a batch file (.bat) - this will be used to schedule a task on system boot. Within the batch file, perform the following:

                   

                  ping 127.0.0.1 -n 2 -w 1000 > NUL

                  ping 127.0.0.1 -n 20 -w 1000 > NULL

                  C:\Windows\system32\mstsc.exe <FULL PATH TO RDP FILE>

                   

                  Essentially we are performing some ping calls as a time delay - since we are executing this on boot, we want to give the system some time to boot up and load all services (especially the terminal services service). Once we perform a wait, we execute the RDP file and create an RDP session into localhost.

                   

                  Now you need to take this batch file and schedule it in Windows Task Schedule. Simply choose the event trigger as "At system startup". I've got mine set up to run with highest privileges and to stop the existing instance if a task is already running. I also set up a secondary task which is responsible for re-logging in the user if it gets disconnected somehow - I've found this to be needed. The task configuration is the exact same, with the trigger being "On remote disconnect from user session of <USER>", where <USER> is the user you are logging in from the RDP file.

                   

                  We've additionally set up a weekly server reboot on Sunday evenings - this solution can highlight a bug within Windows where the desktop memory heap is not disposed and executing so many routine RDP connections against the same user session (since its likely the secondary batch process for re-logging in will reconnect into the existing session). Anyhow, its potential that without a restart, you will start to notice that your user account is not logged in. This is due to the above-mentioned issue, so a weekly restart is strongly recommended.

                   

                  If anyone finds this helpful or needs more information please let me know.