Our company had a new Windows App developed to use to connect to a SQL database. When the app is run outside of the domain environment, it works perfectly. When the computer running it is attached to the domain, the app immediately crashes.
I've found a couple of errors that I think might indicate the problem, but I'm not sure how to interpret them exactly, or what might be impeding the program. I don't believe its an issue with the firewall, as the program works fine when the PC is off the domain. I've combed through every group policy setting, and there doesn't seem to be anything there that could be inhibiting the app's operation either, though it does seem like a likely culprit given the circumstances.
Here are the errors:
Faulting application name: WcBc.UWP.exe, version: 188.8.131.52, 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_184.108.40.206_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_220.127.116.11_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_18.104.22.168_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
Dev people should be able to tell you where exactly it is failing but I'm going to assume its security of the folder within WindowsApps. Try to run the app with elevated rights and see if that works.
If yes, then I'd say the app isn't correctly developed as users can't usually write into Program Files but can into ProgramData where any application generated data should be saved.
If not, provide them access to your environment so they can test it within your environment and debug or ask them to write a detailed log into a file which will help with analysis.
PS if you can, setup a quick domain with SQL server and test it within default environment. If it works there, it's group policy so work backwards by adding one after another until you find where it breaks.
Since you're working to reverse engineer, it looks like you can identify the filter proper using the filter run-time ID.
From the docs [here], you should be able to determine the blocking layer via
netsh wfp show filters and look for 71531 the filter run time ID (Filter Run-Time ID: 71531
Filter Run-Time ID [Type = UInt64]: unique filter ID which blocked the packet.
To find specific Windows Filtering Platform filter by ID you need to execute the following command: netsh wfp show filters. As result of this command filters.xml file will be generated. You need to open this file and find specific substring with required filter ID ()
That should give you a place to start. outside of GPO, there are some other items that may make sense to troubleshoot:
Kerberos & Authentication: Is the SQL server on the domain as well? is it being used by DNS name or IP? SQL account or domain account? Is there a time difference of greater than 5 minutes? (https://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html)
Receiving Side Firewall: You're connecting to a different subnet, is it possible that there is a firewall/route issue that needs to be configured?
best of luck!
User contributions licensed under CC BY-SA 3.0