Archive for the ‘Debugging’ Category

Die mysteriöse Windows 10 App mit Namen “App-Verbindung” bzw. “App connector” oder wie bekommen ich mehr Infos über unbekannte installierte Apps?

13 Mai 2016

Wer bei seinem Windows 10 aufmerksam seine Einstellungen für den Datenschutz studiert, dem wird die App “App-Verbindung” auffallen. Sie taucht z. B. bei Position, Kamera, Kontakte und Kalender auf.

Schon seit letztem Jahr wird spekuliert, was es mit der App auf sich hat: http://www.howtogeek.com/247661/nobody-knows-what-windows-10s-app-connector-is-and-microsoft-wont-explain-it/. Oder http://superuser.com/questions/1003207/windows-10-what-is-the-microsoft-app-connector-and-why-would-it-want-need-acc. Die Officehilfe erwähnt die App sogar im Zusammenhang mit Synchronisationsproblemen mit Windows Mail oder Windows Kalender: https://support.office.com/de-de/article/Beheben-von-Synchronisierungsproblemen-in-den-Mail-und-Kalender-Apps-in-Windows-10-0dd86c69-18f3-4f73-9d3d-375bdc9c3e34. Wie so oft gibt es keine ordentliche Beschreibung von Microsoft oder vernünftige Quellenangaben.

Also versuchen wir mal die nötigen Infos selber zusammen zu tragen. Dabei kann man die prinzipielle Vorgehensweise hier für beliebige Apps unter Windows 10 verwenden.

Man kann sich mittels Powershell nähere Infos zur App holen, indem man

Get-AppxPackage -AllUsers |where name -eq "Microsoft.Appconnector"

eingibt, erhält man z. B.

Name                   : Microsoft.Appconnector
Publisher              : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture           : Neutral
ResourceId             :
Version                : 1.3.3.0
PackageFullName        : Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe
InstallLocation        : C:\Program Files\WindowsApps\Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe
IsFramework            : False
PackageFamilyName      : Microsoft.Appconnector_8wekyb3d8bbwe
PublisherId            : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-1001 [WIN\user]: Installed}
IsResourcePackage      : False
IsBundle               : False
IsDevelopmentMode      : False

Von Interesse dabei ist der Installationspfad. Da kann man dann selber nachschauen, was die App so kann und macht. Jede App unter Windows hat eine Manifest-Datei, in welcher festgelegt ist, welche Zugriffsrechte die App möchte.

Also holen wir uns einfach doch mal diese Manifest-Datei:

$app=Get-AppxPackage -AllUsers |where name -eq "Microsoft.Appconnector"
$mf=[xml](Get-content "$($app.InstallLocation)\AppxManifest.xml")

In $mf steht nun der komplette Manifest-Dateiinhalt zur Verfügung. Durch die Verwendung des Typkonverters [xml] auch noch leicht verwertbar. Schauen wir uns mal einen Eintrag an:

$mf.Package.Applications.Application.VisualElements

DisplayName       : ms-resource:ConnectorStubTitle
Description       : ms-resource:ConnectorStubTitle
BackgroundColor   : transparent
AppListEntry      : none
Square150x150Logo : images\Logo.png
Square44x44Logo   : images\AppConnectorAppList.png
SplashScreen      : SplashScreen

Nicht sehr ergiebig oder? Allerdings ist ein Eintrag interessant, nämlich AppListEntry. Dieser ist mit None definiert und genau dieser ist es, warum die App nicht im Startmenü oder bei der Suche mittels Cortana auftaucht! Weitere Infos zu VisualElements bzw AppListEntry: https://msdn.microsoft.com/en-us/library/windows/apps/dn934817.aspx.

Neben VisualElements ist dann noch das Element Capabilities von Bedeutung:

($mf.Package.Capabilities).Capability

Name
—-
internetClient
picturesLibrary
videosLibrary
removableStorage
appointments
contacts
phoneCall

Es definiert, worauf die App Zugriff haben möchte. Also unsere unbekannte App möchte ins Internet, unsere Bilder und Videos anschauen können, auf Wechseldatenträger zugreifen, Kontakte und Termine sehen und zu guter Letzt noch die Anruferliste sehen. Also eine ganze Menge!

Aber das war noch nicht alles, sie will auch noch auf die Webcam zugreifen und Positionen abfragen:

($mf.Package.Capabilities).DeviceCapability

Name
—-
webcam
location

Zum Themenkomplex Capabilities findet man hier noch weitere Infos: https://msdn.microsoft.com/en-us/library/windows/apps/dn934741.aspx.

Für die Frage aber, was die App denn nun macht ist folgender Eintrag relevant:

$mf.Package.Applications.Application

Id  StartPage    VisualElements
–  ———    ————–
App default.html VisualElements

Der sagt nichts anderes aus, dass wenn App-Verbindung gestartet wird, dass dann default.html aufgerufen wird. Also eine lokale Internetseite. Deren Inhalt kann man sich auch ganz einfach wieder anschauen:

Get-Content "$($app.InstallLocation)\$($mf.Package.Applications.Application.StartPage)"

und erhält:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title id="applicationName"></title>

    <!– Connector.StubApplication references –>
    <link href="/css/default.css" rel="stylesheet" />
    /js/font%20style=
</head>
<body>
</body>
</html>

Also da passiert jetzt nicht so wahnsinnig viel. Allerdings könnte ja nun mittels default.js die Party abgehen. Also holen wir uns den Inhalt auch noch:

$html=[xml](get-content "$($app.InstallLocation)\$($mf.Package.Applications.Application.StartPage)")

Wir nutzen wieder den Typekonverter um das gewünschte Ziel schneller auslesen zu können. Denn wir sind an

$html.html.head.script

src

/js/default.js

interessiert, denn damit bekommen wir den Inhalt des Javascripts mittels

get-content "$($app.InstallLocation)\$($html.html.head.script.src)"

ausgelesen:

(function () {
    "use strict";
    function setTextContent(elementId, stringId) {
        var resources = new Windows.ApplicationModel.Resources.ResourceLoader();
        document.getElementById(elementId).textContent = resources.getString(stringId);
    }

    function updateUserInterface() {
        setTextContent("applicationName", "ConnectorStubTitle");
    }

    document.addEventListener("DOMContentLoaded", function domContentLoaded() {

        MSApp.terminateApp(new Error("This app should never load"));

    }.bind(this));
})();

Das Javascript definiert eine anonyme Funktion und fügt dem Application-DOM einen EventListener hinzu, der darauf reagiert, wenn DOMContentLoaded ausgelöst wird. Aber jetzt kommt das Highlight, falls dies der Fall sein sollte, dann wird die App mit einer Fehlermeldung “This app should never load” abgebrochen!!

Ja was den nun? Für was gibt es eine App, wenn sie nicht geladen werden soll?

OK, manchmal gibt es ja Apps die sind für etwas Besonderes zuständig und haben gar keine UI, wie z. B. Dienste oder Proxys. Ist dies hier vielleicht der Fall?

$mf.Package.Extensions -eq $null
True

Also nix mit Extensions, nada niente.

Übrigens die fürs Wohlergehen zuständige Bing Health und Fitness App liefert z. B. so etwas:

$mfb.Package.Extensions

Extension
———
{Extension, Extension, Extension, Extension…}

$mfb.Package.Extensions.Extension

Category                                 ProxyStub
——–                                 ———
windows.activatableClass.proxyStub       ProxyStub
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer

Hier die Beschreibung zu den Extensions und was da möglich ist: https://msdn.microsoft.com/en-us/library/windows/apps/dn934750.aspx. Um es gleich zu sagen, das ist eine Menge! Aber davon, wie gesagt, ist hier nichts gegeben.

Schauen wir noch auf einen weiteren interessanten Parameter, welche Versionsanforderungen die App hat:

$mf.Package.Dependencies.TargetDeviceFamily

Name              MinVersion   MaxVersionTested
—-              ———-   —————-
Windows.Universal 10.0.10069.0 10.0.10069.0

So so, hier wird also eine Buildnummer 10069 als Minimum genannt. Übrigens 10069 war eine Beta vor dem April 2015! Nun gut, bei Top-Programmen kann man das so stehen lassen. Witzig wird aber der Parameter MaxVersionTested. Der besagt, dass 10069 die neueste Version ist, mit welcher die App getestet wurde, was irgendwie null Sinn ergibt, denn es sind ja mittlerweile viele andere Versionen herausgekommen?!?!? Ist das aktives Qualitätsmanagement ala Microsoft?
Noch Infos zu den Dependencies: https://msdn.microsoft.com/en-us/library/windows/apps/dn986903.aspx.

Sei es wie es will, die App macht absolut keinen Sinn.

Übrigens taucht sie wieder an weiterer Stelle auf, wo man nicht unmittelbar mit ihr rechnet. In der Windows Firewall. Dort ist jede App registriert die mit dem Internet kommuniziert:

Get-NetFirewallRule | where DisplayName -eq "App-Verbindung"

Name                  : {F9CB7621-DFB0-4F00-BDB1-8D54D0D53710}
DisplayName           : App-Verbindung
Description           : App-Verbindung
DisplayGroup          : App-Verbindung
Group                 : @{Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe?ms-resource://Microsoft.Appconnector/Resources
                        /ConnectorStubTitle}
Enabled               : True
Profile               : Domain, Private, Public
Platform              : {6.2+}
Direction             : Outbound
Action                : Allow
EdgeTraversalPolicy   : Block
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 : S-1-5-21-XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-1001
PrimaryStatus         : OK
Status                : Die Regel wurde erfolgreich vom Speicher aus analysiert. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

Wie kann man nun diese Ominöse App loswerden, ohne dass man jedes einzelne Einstellungsmenü durchgehen muss? Man verwendet einfach Remove-AppXPackage:

Remove-AppXPackage –Package $app.PackageFullName

Dadurch verschwindet die App aus allen Menüs wie bei den Datenschutz-Einstellungen. Schaut man sich aber den Installationspfad an, dann ist sie immer noch vorhanden, könnte also potentiell irgendeinen Blödsinn ausrichten. Also am besten entsorgt man das komplette Paket von der Platte:

$pro=Get-AppxProvisionedPackage -Online | where Displayname -eq $app.name
$pro

DisplayName  : Microsoft.Appconnector
Version      : 2015.707.550.0
Architecture : neutral
ResourceId   : ~
PackageName  : Microsoft.Appconnector_2015.707.550.0_neutral_~_8wekyb3d8bbwe

 

Remove-AppxProvisionedPackage -Online -PackageName $pro.PackageName

Path          :
Online        : True
RestartNeeded : False

So jetzt ist endlich Schluss mit dem Schrott. Zum Abschluss muss ich noch einen Ablassen über die Officesupport-Artikel…

Mittels Powershell geladene DLL-Dateien aus einem Prozess auslesen

4 Januar 2016

Öffnet man unter Windows die Eingabeaufforderung, so kann man mit TASKLIST.EXE die aktuell ausgeführten Programme bzw. Prozesse auflisten. Bei den Optionen kann man /M angeben, dann werden zu jedem Prozess die geladenen DLL-Dateien angezeigt.

Hier ein Beispiel von Windows 8.1:

tasklist /FI "imagename eq cmd.exe" /M

Abbildname                     PID Module
========================= ======== ============================================
cmd.exe                      15872 ntdll.dll, KERNEL32.DLL, KERNELBASE.dll,
                                   msvcrt.dll, winbrand.dll

Nun ist es wie immer schwierig von einer Textausgabe die Daten weiterzuverarbeiten. Aber es gibt ja Powershell und das äquivalente Kommando in Powershell sieht so aus:

Get-CimInstance -ClassName Win32_Process -Filter "Name=’cmd.exe’" | Get-CimAssociatedInstance -Association Cim_ProcessExecutable | ft name

die Ausgabe sieht dann so aus:

name
—-
c:\windows\system32\cmd.exe
c:\windows\system32\ntdll.dll
c:\windows\system32\kernel32.dll
c:\windows\system32\kernelbase.dll
c:\windows\system32\msvcrt.dll
c:\windows\system32\winbrand.dll

da es aber nun Objekte sind, kann man natürlich auch mehr Infos anfordern:

Get-CimInstance -ClassName Win32_Process -Filter "Name=’cmd.exe’" | Get-CimAssociatedInstance -Association Cim_ProcessExecutable | ft name, version

name                               version
—-                               ——-
c:\windows\system32\cmd.exe        6.3.9600.17415
c:\windows\system32\ntdll.dll      6.3.9600.17736
c:\windows\system32\kernel32.dll   6.3.9600.17415
c:\windows\system32\kernelbase.dll 6.3.9600.17415
c:\windows\system32\msvcrt.dll     7.0.9600.17415
c:\windows\system32\winbrand.dll   6.3.9600.17415

Mit etwas Aufwand kann man sich auch einen Prozessbaum bauen: https://p0w3rsh3ll.wordpress.com/2012/10/12/show-processtree/

Mittels Get-CimAssociatedInstance kann man sowieso noch jede Menge interessante Dinge in Erfahrung bringen, z. B. wer angemeldet ist, welche Partitionen ein Laufwerk enthält usw. http://csharpening.net/?p=876.

Für Powershell .Net Framework Tracing aktivieren

13 Dezember 2014

Manchmal ist nicht klar warum etwas nicht funktioniert. Da Powershell stark auf das .Net Framework angewiesen ist, kann man auch dessen Trace-Möglichkeiten nutzen, um eine tiefergehende Fehleranalyse zu ermöglichen. Hilfreich ist das Tracing z. B. in Verbindung mit der Netzwerkkommunikation.

Unter .Net kann man das Netzwerktracing wie in diesem Artikel beschrieben aktivieren: http://msdn.microsoft.com/en-us/library/ty48b824(v=vs.110).aspx. Damit der Trace-Mitschnitt in Powershell aktiviert werden kann, muss die in der betreffenden Powershellversion die Datei Powershell.exe.config angelegt, bzw. bearbeitet werden. Dabei ist von Bedeutung, ob man mit Powershell 32-Bit oder 64-Bit arbeitet. Zum Thema Powershell 32-/64-Bit siehe hier: https://newyear2006.wordpress.com/2012/06/20/prfen-ob-eine-powershell-sitzung-in-einer-32bit-oder-64bit-prozess-umgebung-luft/.

Kurz: Unter einem 64-Bit System findet man die 64-Bit Powershell-Version unter C:\WINDOWS\SYSTEM32\WINDOWSPOWERSHELL\V1.0 und die 32-Bit Powershell-Version unter C:\WINDOWS\SYSWOW64\WINDOWSPOWERSHELL\V1.0. Auf einem reinen 32-Bit-System ist der Pfad wieder wie bei der 64-Bit Fassung.

Wenn man nun also seine Powershell.exe.config, die so aussieht

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

   <system.diagnostics>

        <sources>

            <source name="System.Net">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

            <source name="System.Net.Sockets">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

        </sources>

        <switches>

            <add name="System.Net" value="Verbose" />

            <add name="System.Net.Sockets" value="Verbose" />

        </switches>

        <sharedListeners>

            <add name="System.Net"

                type="System.Diagnostics.TextWriterTraceListener"

                initializeData="System.Net.log"

                />

        </sharedListeners>

        <trace autoflush="true" />

    </system.diagnostics>

</configuration>

im Verzeichnis C:\Windows\System32\WindowsPowershell\V1.0\ angelegt hat, kann man anschließend Powershell starten. Wichtig, die Einstellungen wirken sich erst aus, wenn eine neue Powershell.exe gestartet wird.

Man bekommt nun in der Datei System.Net.Log die Trace-Daten gespeichert. Die System.Net.Log wird in dem Verzeichnis der Powershell.exe gespeichert.

Möchte man die Trace-Möglichkeit in Powershell-ISE nutzen, muss man natürlich die Datei Powershell_ise.exe.config bearbeiten.

Das Format der Trace-Daten ist kurz hier angerissen: http://msdn.microsoft.com/en-us/library/46fcs6sz(v=vs.110).aspx.

Tschüss Microsoft Netzwerkmonitor (NetMon), willkommen MessageAnalyzer!

26 Oktober 2012

Endlich geht es voran mit der neuen Version des Microsoft Netzwerkmonitors. Aber nicht einfach eine Nachfolgeversion mit erweiterten und angepassten NPL-Dateien für Windows 8 und Server 2012 erscheint sondern eine komplett überarbeitete Version. Dies trägt vor allem dem Umstand Rechnung, dass der NetMon nicht nur für Netzwerkpakete sondern mittlerweile für alle möglichen Protokolle in Microsoft Systemen vorgesehen ist. Sei es Exchange, Sharepoint, SMB, NDIS, USB oder Systemereignisse bei allem kann man NetMon und in Zukunft den MessageAnalyzer einsetzen.

Hier ein paar Artikel, welche verdeutlichen was mit der alten Version bereits möglich war: https://newyear2006.wordpress.com/2012/07/06/mitschneiden-von-netzwerkverkehr-am-virtuellen-switch-eines-hyper-v-version-3-servers/, https://newyear2006.wordpress.com/2009/12/27/usb-probleme-in-windows-7-analysieren-und-verstehen/ und https://newyear2006.wordpress.com/2009/08/26/netzwerkprobleme-unter-windows-7-analysieren/.

Durch die neue Version werden nun automatisch alle aktuellen Protokolle unterstützt und darüberhinaus sind jede Menge sinnvolle neue Funktionen enthalten.

Blog: http://blogs.technet.com/b/messageanalyzer/

Minidump Crashdump Analyse unter Windows XP bis Server 2008 R2

29 September 2011

Ein Thema das keiner liebt aber sicher fast jeden mit einem Bluescreen schon mal gegrüßt hat sind die Abstürze wenn Treiber versagen. Aus aktuellem Anlass hier mal ein paar Links wo man zuerst Infos zum Thema bekommt, und was man wie einstellen kann: http://support.microsoft.com/kb/254649

Die Minidump werden unter %SystemRoot%\Minidump gespeichert, also in der Regel unter C:\WINDOWS\Minidump. Was macht man dann aber mit so einer Datei? Hier wirds beschrieben: http://support.microsoft.com/kb/315263/en-us

Hier gibts die nötigen Debugging Tools: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Happy Debugging!

Standarddienste auf Small Business Server

21 Juli 2011

Um bei Problemen mit einem Small Business Server schneller prüfen zu können woran ein Problem liegt, ist es natürlich hilfreich zu wissen welche Dienste normalerweise laufen.

Hier für SBS 2011: http://blogs.technet.com/b/sbs/archive/2011/07/13/default-services-and-their-status-in-sbs-2011.aspx

für SBS 2008:
http://msmvps.com/blogs/bradley/archive/2009/06/05/default-sbs-2008-running-services.aspx

und für 2003:
http://support.microsoft.com/kb/829623

Wenn man noch weitere Infos über Dienste erfahren möchte, ist folgendes noch interessant:
https://newyear2006.wordpress.com/2011/04/28/bersicht-und-beschreibungen-ins-detail-ber-dienste-in-windows-systemen/

Übersicht und Beschreibungen ins Detail über Dienste in Windows Systemen

28 April 2011

Vom alten Windows XP 32Bit ohne Service Pack bis Windows 7 64Bit mit Service Pack 1 werden alle möglichen Dienste sehr detailliert beschrieben. Zugleich findet man Vergleiche welche Dienste auf welcher SKU aktiviert sind. Man findet mögliche Alternativen um mit weniger Resourcen auszukommen.

Einfach genial. Fragt man sich warum MS dann nicht hinbekommt. Nicht einmal im Resource Kit gibt es eine so umfangreiche Auflistung der Dienste, deren Abhängigkeiten sowie Beschreibungen.

http://www.blackviper.com/wiki/Main_Page

Outlook 2010 Logging

19 April 2011

Interessanter KB-Artikel, wo und was Outlook 2010 alles mitloggen kann: http://support.microsoft.com/kb/2498869

E-Mail Header Zeilen Analysieren

19 Januar 2011

Bei Problemen ist es hilfreich, wenn man weiß wo man nachschauen kann und wo es weitere Infos gibt. Beim letzten Problem mit den Umlauten in Outlook https://newyear2006.wordpress.com/2011/01/18/outlook-problem-mit-umlauten-anstatt-werden-weie-fragezeichen-in-schwarzen-rauten/ stellte sich hin und wieder die Frage was der einzelne Eintrag im E-Mail-Header was für eine Bedeutung hat. Bestimmte Standardeinträge sind klar, aber nicht die Erweiterungen wo von verschiedenen Programmen eingetragen werden. Ebenso stellt sich oft die Frage, wo der betreffende Webmailer oder das E-Mail-Programm die Headerinformationen versteckt hält.

Eine gute Seite mit vielen Infos zu diesen Themen ist diese: http://th-h.de/faq/headerfaq.php

Wireshark Anzeigefilter per Kommandozeile mitgeben

2 Januar 2011

Für bestimmte Auswertungen kann es ganz interessant sein bei Wireshark den zu verwendenden Anzeigefilter per Kommandozeile mitzugeben.

Beispiel:

wireshark –r inputfile.pcap –R "ip.dst == 74.208.164.166"

Im obigen Beispiel wird z. B. die IP-Adresse eines sinkhole von Shadowserver.org angegeben. Allerdings stehen einem dann die restlichen Pakete aus inputfile.pcap nicht zur Verfügung, somit reagiert –R nicht als Anzeigefilter sondern gleich als Lesefilter.

Aber für den schnellen Blick, ob bestimmte Pakete enthalten sind oder nicht sicherlich sinnvoll.