WCF Proxy Submit Crash - процесс убийств - PullRequest
0 голосов
/ 14 февраля 2011

У меня есть простой сервис WCF, который принимает некоторые данные (wsHttpBiding) и возвращает результат.На стороне клиента dll, содержащая прокси-оболочку, загружается и используется для создания / отправки запроса в службу.

В большинстве случаев это работает отлично, но для некоторых пользователей вызов отправки отправляетсяклиентский прокси приводит к немедленному падению приложения (без ошибок, предупреждений и т. д., процесс просто мгновенно умирает)

Эта проблема, похоже, связана с учетной записью Windows: разные пользователи, вошедшие в систему на одном компьютере, делаютне испытываю проблемы.

Ищу мысли о том, где я мог бы начать искать виновника.Есть какие-нибудь идеи?

Редактировать :

  1. Я пытаюсь получить версию с некоторыми инструкциями трассировки и регистрации ошибок в ней на затронутые машиныв данный момент.В вызове .submit нет попытки / перехвата, но исключения не должны распространяться обратно через стек вызовов (DLL / клиентский прокси-сервер загружается непосредственно в основной домен приложения, но любые другие исключения, такие как тайм-ауты, просто передаются обратнок хост-приложению, как и ожидалось)
  2. Web.Config на стороне сервера, как показано ниже
  3. Пользователи находятся в том же домене, что и другие пользователи, используются учетные данные по умолчанию.В домашнем приложении сервер находится в одной сети.

Служба Web.Config:

<system.serviceModel>
    <behaviors>
        <serviceBehaviors>
            <behavior name="Services.EventsBehavior">
                <serviceMetadata httpGetEnabled="true" />
                <serviceDebug includeExceptionDetailInFaults="true" />
                <serviceThrottling maxConcurrentSessions="100" />
            </behavior>
            <behavior name="Services.LayoutsBehavior">
                <serviceMetadata httpGetEnabled="true" />
                <serviceDebug includeExceptionDetailInFaults="true" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
    <services>
        <service behaviorConfiguration="Services.EventsBehavior" name="Services.Events">
            <endpoint address="" binding="wsHttpBinding" contract="Services.IEvents">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
            <host>
                <timeouts openTimeout="00:00:45" />
            </host>
        </service>
        <service behaviorConfiguration="Services.LayoutsBehavior" name="Services.Layouts">
            <endpoint address="" binding="wsHttpBinding" bindingConfiguration="largeRequestMsg" contract="Services.ILayouts">
            <identity>
                <dns value="localhost" />
            </identity>
            </endpoint>
            <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        </service>
    </services>
    <bindings>
        <wsHttpBinding>
            <binding name="largeRequestMsg" maxReceivedMessageSize="5000000"></binding>
        </wsHttpBinding>
    </bindings>
</system.serviceModel>

Обновление: (2011/03/18) Итак, я смог провести небольшое тестирование (наконец) и, к сожалению, не может воспроизвести проблему с помощью тестового жгута на клиентском компьютере.

Это наводит меня на мысль, что при вызове моего клиента dll (через COM) происходит что-то интересное, что вызываетвопрос.

Есть мысли?

1 Ответ

0 голосов
/ 20 февраля 2011

, чтобы получить больше информации, попробуйте включить трассировку WCF и использовать утилиту трассировки viwer для чтения сообщений об ошибках, если источником является операция WCF. вот ссылка о том, как это сделать, это не сложно.обратите внимание, что файл трассировки может быть большим.не оставляйте трассировку дольше времени, необходимого для сбора данных.(машина разработки здесь идеально подходит, если это возможно)

Еще одна вещь, немедленный сбой без предупреждения, возможно, связана с тем, что ошибка возникает в потоке, отличном от основного потока графического интерфейса.(таким образом, вызов WCF - это действительно место, где можно начать поиск).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...