Алгоритм работы сервиса таков
1)Перед непосредственно обращением к сервису идет аутентификация в IIS через настроенное сопоставление. Возможно, я чего-то не знаю, но 90% (а может и больше) обращений в техподдержку связаны именно с ошибками на этой стадии.
До сервиса тут дело еще не доходит, поэтому тут в диагностике лучше всего помогут логи IIS, а если все совсем плохо - то сообщения от CSP и TLS в журнале приложений. Так же со своей стороны Росреестр тоже собирает какие-то данные, которые в теории могут помочь понять причину.
2)До вызова самого сервиса дойдет, но возникнет какая-то непредвиденная ошибка в процессе выполнения запроса Росреестра - будет возбуждено исключение, которое попадет в лог .NET, если он включен.
3)Если сервис отработал нормально, то по результатам работы обязательно будет выдан протокол в формате, согласованным с Росреестром, где будет указан общий результат + если есть возникшая ошибка - описание и стадия, на которой она появилась.

Вопрос о небольшой доработке сервиса рассмотреть можно, только поясните пожалуйста:
В каких ситуациях планируется использовать новый журнал? Какого рода информация туда должна попадать? В каком виде предпочтительней было бы ее получать?

Если можно отвечу по пунктам.
1. Использовать новый журнал планируется, исключительно, для подтверждения факта получения данных о конкретном клиенте нашего УЦ, данная информация новой не будет, так как УЦ ее и накапливает в своей базе. Поясню, к нам обратился Петр Петрович Петров, он обратился в РР за получением выписки из ГКН. Росреестр возвращает ошибку, смотрим, что отдалось Росреестру в протоколе (описанном в Вашем посте выше), выясняем что Петр Петрович дал неверные данные о себе или Оператор УЦ ошибся и внес не корректные данные. Вот такие ошибки, было бы гораздо быстрее "мониторить" соответствующим журналом.
2. Я думаю, было бы достаточно вносить туда результат работы сервиса.
3. Вид журнала, проще было бы получать его в виде текстового файла, имхо.

Отредактировано пользователем 12 февраля 2014 г. 13:24:39(UTC)  | Причина: Не указана

Поддержу - очень нужен журнал событий от этого сервиса, дабы видеть, что и как запрашивают пользователи.

То есть о том, что происходит внутри ExpandedData.

Неожиданный поворот :)
Сервис устроен очень просто - он получает сертификат, в БД ЦР ищет по нему пользователя, у пользователя берет уже готовый документ, сформированный по схеме Росреестра, и отдает его наружу.
Документ формируется редактором, прилагающимся к сервисе, который тоже устроен очень просто - берет набор текстовых строк, сериализует их в XML по схеме Росреестра и кладет в базу для определенного пользователя.
Таким образом, если Росреестр увидит какую-то ошибку в документе, то просмотр и поиск несоответствий намного проще выполнить через редактор, чем разбирать XML, пусть даже и отформатированный.
Но зато такое логгирование очень поможет, если есть подозрения на ошибки в работе сервиса (неверный поиск например) и/или редактора (сериализация).
Правильно?

Хотелось бы уточнить, будет ли доработка ?