Приложение сразу же вылетает при запуске с компьютера, входящего в домен. Когда компьютер выводится из домена, оно работает нормально.

Приложение сразу же вылетает при запуске с компьютера, входящего в домен. Когда компьютер выводится из домена, оно работает нормально.

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

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

Вот ошибки:

Журнал приложений

Faulting application name: WcBc.UWP.exe, version: 1.0.0.0, time stamp: 0x5e1b7efb
Faulting module name: ntdll.dll, version: 10.0.18362.418, time stamp: 0x99ca0526
Exception code: 0xc0000005
Fault offset: 0x000000000001792d
Faulting process id: 0x5e2c
Faulting application start time: 0x01d5cd738a0fa05b
Faulting application path: C:\Program Files\WindowsApps\WcBc_6.0.3.0_x64__x092f3jx59vf4\WcBc.UWP.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: fc0e2bd5-9704-4ad2-b601-b61c8bfd53a7
Faulting package full name: WcBc_6.0.3.0_x64__x092f3jx59vf4
Faulting package-relative application ID: App

Журнал безопасности

The Windows Filtering Platform has blocked a packet.

Application Information:
               Process ID:                           24108
               Application Name:              \device\harddiskvolume3\program files\windowsapps\wcbc_6.0.3.0_x64__x092f3jx59vf4\wcbc.uwp.exe

Network Information:
               Direction:                             Outbound
               Source Address:                   10.80.243.64
               Source Port:                         58988
               Destination Address:           10.101.10.18
               Destination Port:                 4118
               Protocol:               6

Filter Information:
               Filter Run-Time ID:              71531
               Layer Name:                         Connect
               Layer Run-Time ID:              48

решение1

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

Если да, то я бы сказал, что приложение разработано неправильно, поскольку пользователи обычно не могут писать в Program Files, но могут в ProgramData, где должны сохраняться все данные, созданные приложением.

Если нет, предоставьте им доступ к вашей среде, чтобы они могли протестировать ее в вашей среде и выполнить отладку, или попросите их записать подробный журнал в файл, который поможет с анализом.

P.S. если можете, настройте быстрый домен с SQL-сервером и протестируйте его в среде по умолчанию. Если он работает там, это групповая политика, поэтому работайте в обратном порядке, добавляя одно за другим, пока не найдете, где он ломается.

решение2

Поскольку вы занимаетесь обратным проектированием, похоже, вы можете идентифицировать фильтр, используя идентификатор времени выполнения фильтра.

Из документации [здесь][1] вы сможете определить блокирующий слой с помощью netsh wfp show filtersи поиска 71531 идентификатора времени выполнения фильтра (Идентификатор времени выполнения фильтра: 71531

Filter Run-Time ID [Type = UInt64]: unique filter ID which blocked the packet.

Чтобы найти определенный фильтр Windows Filtering Platform по ID, вам необходимо выполнить следующую команду: netsh wfp show filters. В результате этой команды будет сгенерирован файл filter.xml. Вам необходимо открыть этот файл и найти определенную подстроку с требуемым идентификатором фильтра ()

Это должно дать вам отправную точку. Помимо GPO, есть еще несколько элементов, устранение неполадок в которых имеет смысл:

Kerberos и аутентификация: SQL-сервер также находится в домене? Используется ли DNS-имя или IP-адрес? Учетная запись SQL или учетная запись домена? Разница во времени составляет более 5 минут? (https://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html)

Брандмауэр на принимающей стороне: вы подключаетесь к другой подсети. Возможно, возникла проблема с брандмауэром/маршрутом, которую необходимо настроить?

удачи!

Связанный контент