Ich habe seit kurzem ein Problem mit der Lauffähigkeit einer WPF Anwendung unter Win10, das gemeine daran ist das das nicht bei jedem Rechner der Fall ist. Auf dem Rechner mit VS 2015 (FW 4.5.2) ist kein Problem auf einem anderen mit Win10 ohne VS auch nicht nur an einem bestimmten wird die Applikation nicht gestartet. Habe schon alle benötigten Dateien und Bibliotheken kontrolliert, unter Win7 gab es ja auch keine Probleme und am Anfang unter Win10 auch nicht erst seit einem Windows Update. Beim Start kommt auch keine Exception oder irgendwas dergleichen wird einfach nicht gestartet (Unhandled-Exception wird nicht geworfen), kann also auch schlecht debuggen. Hat jemand von euch schon mal sowas gehabt und kann mir da vielleicht einen Tipp geben. Hab auch schon Stundenlang GOOGLE ausgequetscht aber da gibt es wahrscheinlich 1000 Ursachen für.
Weiß echt nicht mehr weiter?????????
Gibt es in der Ereignisanzeige keine Meldung?
Bzw. was zeigt z.B. ein Startversuch über cmd/powershell an?
Ansonsten wäre auch die Frage, wie du die Anwendung bereitstellst.
I.d.R. solltest du hier einen Release Build erstellen und per Publish lokal bereitstellen lassen.
Dann kannst du den Ordner mit der Anwendungen samt den Libs dazu verteilen.
Damit sind schon fehlende DLLs o.ä. ausgeschlossen.
Ansonsten sollte auch .NET in der aktuellen Version (4.8 bei Framework Anwendungen) auf den jeweiligen Systemen installiert sein.
Hier sollte sich aber .NET beim Start melden, wenn die Laufzeitumgebung fehlt.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Ist mir klar das ihr keine glaskugel habt. Die app ist ein release.
Das mit dem eventlog hab ich noch nicht probiert aber dass werde ich gleich mal probieren.
Hallo zusammen
So habe die letzten 3 Tage damit verbracht alles zu versuchen hatte leider keinen Erfolg gehabt.
Ich kann die App auf einem bestimmten Client Rechner mit Win10 nicht starten.
Habe mir eine neues Projekt angelegt mit nichts außer den Standarddateien einer neuen Wpf App.
Wenn ich diese auf dem besagten Client starte funktioniert sie wenn ich in das MainWindow ein Frameworkelement (Textblock, Button, RadioButton) gebe geht es auch noch doch sobald ich einen Content festlege kracht es beim Start ohne Exception (bei einer Combobox wird die App sofort gekillt auch ohne Items). Beim Titel von dem MainWindow selbst gibt es keine Probleme.
.NetRuntime
Anwendung: WpfApplication3.exe Frameworkversion: v4.0.30319 Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet. Ausnahmeinformationen: Ausnahmecode c0000005, Ausnahmeadresse 0000000000000000
Jo, steht ja in der Fehlermeldung: Gibt ne Exception und Du behandelst sie nicht.
Wir wissen auch nicht, welche Exception das ist. Das musst jetzt halt heraus finden.
Wenn ich das ganze über Publish lokal bereitstelle dann wird die App zwar nicht gekillt aber auch nicht gestartet.
Vermutlich fehlt Dir was, aber wir sehen halt noch weniger als Du siehst.
Musst halt mal die Systeme vergleichen, was unterschiedlich ist.
.NET, SDK. Abhängigkeiten...
Im Error wird von v4.0.30319 gesprochen; bin mir nicht wirklich sicher, dass das der Identifier für 4.6.1 sein soll.
Weiter oben sprichst Du, dass auf dem Rechner nur 4.5.2 ist.
Edit: ich sehe gerade, dass die Applikation auf Q liegt, was nach Netzlaufwerk riecht.
Das Rechtemanagement von Windows reagiert sehr sensibel auf Netzwerklaufwerke und wenn da was nicht stimmt, dann wird Deine Anwendung unempfindlich abgeschossen bzw. Depenendcies werden nicht geladen und Deine Anwendung knallt.
Das is aber prinzipiell kein .NET Problem, sondern allgemein ein "Problem" bzw. eine Situation seit Windows 98.
Dein Problem scheint dann aber irgendwo anders im Code aufzutreten und dort wird die Exception nicht gefangen.
Dein Init kann dann auch nicht die Ursache sein, da Fertig ausgegeben wird.
Hast du den Code mal debuggt?
Dann müsste die Ursache direkt angezeigt werden.
Hast du ggf. ein Event wie Form_Load oder bei einem Control ein Load Event?
Dann kann es da noch knallen.
T-Virus
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von T-Virus am .
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Das ist ja mein Problem es wird keine Exception geworfen
Wenn ich in der Init() Methode eine Division durch null mache dann wird eine Unhandled Exception geworfen und verarbeitet aber in diesem Fall eben nicht
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Qt21580 am .
Wenn es eine unbehandelte Ausnahme gibt, wird das entsprechende Ereignis ausgelöst.
AccessViolationExceptions (genauer gesagt alle SEHExceptions) können seit .NET 4 nicht mehr einfach gefangen werden. Der Prozess wird beendet und ein Eintrag in das Ereignisprotokoll geschrieben.
Zitat
In version 4 and later, the CLR exception system will not deliver CSEs to managed code unless the code has expressly indicated that it can handle process corrupted state exceptions.
Was du versuchen könntest wäre einen Crash-Dump zu erzeugen und diesen dann zu debuggen.
Am einfachsten kannst du dies machen in dem du Procdump verwendest. Stürzt ein Prozess ab wird automatisch ein Memory-Dump erzeugt.
Mit folgendem Batch-Skript kannst du die automatische CrashDump Erstellung aktivieren:
cd %~dp0
md c:\procdumps
procdump -accepteula -ma -i c:\procdumps
Und mit folgendem wieder deaktivieren:
cd %~dp0
procdump -u
(Beide Skripte benötigen Adminrechte zur Ausführung. Beide Skripte zur Procdump-Exe kopieren vor der Ausführung.)
Den Crashdump (aus C:\procdumps) solltest du dann einfach via Drag&Drop in VS ziehen und debuggen können.
Hallo p!lle
Das Ergebniss vom eventlog hab ich schon gepostet.
Mit etwas mehr code ist ein Problem denn bei der Testapp gibt es nichr mehr code als gepostet
es muss definitiv mehr Code geben, denn irgendwo muss deine Anwendung ja gestartet werden. App.cs oder App.xaml oder so ähnlich.
Mir ist auch noch nicht ganz klar, ob du eine Konsolenapp startest und daraus das Fenster öffnest oder ob du eine reine WpfApplication hast.
//App.xaml.cs
using System;
using System.Diagnostics;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Threading;
namespace WpfApplication4
{
/// <summary>
/// Interaktionslogik für "App.xaml"
/// </summary>
public partial class App : Application
{
public App() : base()
{
SetupUnhandledExceptionHandling();
}
private void SetupUnhandledExceptionHandling()
{
// Catch exceptions from all threads in the AppDomain.
AppDomain.CurrentDomain.UnhandledException += (sender, args) =>
ShowUnhandledException(args.ExceptionObject as Exception, "AppDomain.CurrentDomain.UnhandledException", false);
// Catch exceptions from each AppDomain that uses a task scheduler for async operations.
TaskScheduler.UnobservedTaskException += (sender, args) =>
ShowUnhandledException(args.Exception, "TaskScheduler.UnobservedTaskException", false);
// Catch exceptions from a single specific UI dispatcher thread.
Dispatcher.UnhandledException += (sender, args) =>
{
// If we are debugging, let Visual Studio handle the exception and take us to the code that threw it.
if (!Debugger.IsAttached)
{
args.Handled = true;
ShowUnhandledException(args.Exception, "Dispatcher.UnhandledException", true);
}
};
// Catch exceptions from the main UI dispatcher thread.
// Typically we only need to catch this OR the Dispatcher.UnhandledException.
// Handling both can result in the exception getting handled twice.
//Application.Current.DispatcherUnhandledException += (sender, args) =>
//{
// // If we are debugging, let Visual Studio handle the exception and take us to the code that threw it.
// if (!Debugger.IsAttached)
// {
// args.Handled = true;
// ShowUnhandledException(args.Exception, "Application.Current.DispatcherUnhandledException", true);
// }
//};
}
void ShowUnhandledException(Exception e, string unhandledExceptionType, bool promptUserForShutdown)
{
//var messageBoxTitle = $"Unexpected Error Occurred: {unhandledExceptionType}";
var messageBoxMessage = $"The following exception occurred:\n\n{e}";
//var messageBoxButtons = MessageBoxButton.OK;
if (promptUserForShutdown)
{
messageBoxMessage += "\n\nNormally the app would die now. Should we let it die?";
//messageBoxButtons = MessageBoxButton.YesNo;
}
// Let the user decide if the app should die or not (if applicable).
Console.WriteLine(messageBoxMessage);
//if (MessageBox.Show(messageBoxMessage, messageBoxTitle, messageBoxButtons) == MessageBoxResult.Yes)
//{
// Application.Current.Shutdown();
//}
}
}
}
//MainWindow.xaml.cs
using System;
using System.Collections.Generic;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
namespace WpfApplication4
{
/// <summary>
/// Interaktionslogik für MainWindow.xaml
/// </summary>
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
Init();
}
private void Init()
{
try
{
Console.WriteLine("Anfang");
TextBlock tb = new TextBlock();
tb.Text = "Text";
grid.Children.Add(tb);
Console.WriteLine("Fertig");
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
}
ich habe mal deine kompilierte Variante probiert. Diese startet.
Dann habe ich den Code mit und ohne einkommentiertem TextBlock in Debug und Release getestet. Alle vier Kominationen starten ohne Probleme.
Kannst du dich nicht per Remote-Debugging (aus VS heraus) an den Prozess auf dem anderen Rechner hängen? (Wenn ein Prozess schon beim Start abstürzt, nutze ich dazu meist ein (böses!) Thread.Sleep(30000), um genug Zeit zu haben, mich an den Prozess zu hängen).
Ich denke aber, daß der Fehler von einer nativen Komponente verursacht wird (z.B. direkt von der .NET-Laufzeitumgebung).
Stürzt die App denn auch ab, wenn du einen leeren MainWindow-Konstruktor hast (bzw. ohne die Init-Methode)?
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Th69 am .
Nur damit es gesagt sind: WPF Anwendungen stürzen auch ab, wenn der Grafik-Treiber defekt ist.
Aber eigentlich mit einer anderen Fehlermeldung als ACCESS_VIOLATION.
Also ehrlich gesagt, verstehe ich nicht, warum du eine WpfApplicaton als Konsolenanwendung missbrauchst.
Weil dann ein Konsolenfenster verfügbar ist, um schnell Debug-Messages, auf einem nicht-Entwicklungsrechner, auszugeben. Siehe Init-Methode. Darauf nun rumzureiten, obwohl es null mit der Ursache oder Lösung des Problems zu tun hat bringt doch garnix.
Zitat von Th69
Ich denke aber, daß der Fehler von einer nativen Komponente verursacht wird (z.B. direkt von der .NET-Laufzeitumgebung).
Dies sollte klar sein, dass die Laufzeit, Treiber oder sonstige Komponente ein Problem hat und nicht die Anwendung selber. Im Notfall die Runtime neu installieren, System auf Fehler prüfen oder Windows komplett zurückzusetzen.