В нашей компании было разработано новое приложение 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)
Брандмауэр на принимающей стороне: вы подключаетесь к другой подсети. Возможно, возникла проблема с брандмауэром/маршрутом, которую необходимо настроить?
удачи!