Programm startet nicht mehr auf Windows 2003

Hi,

auf einem Windows 2003 Server startet mein Programm plötzlich nicht mehr.
In einer älteren Version funktioniert es noch. Alle Erweiterungen habe ich
im grunde schon auskommentiert, um nachvollziehen zu können wo genau
das Programm hängt.

Ich bin jetzt soweit, dass ich sagen kann, dass InitInstance durchlaufen wird.
Aber was wird nach InitInstance gerufen? OnPaint bzw. OnInitDialog erreicht
das Programm schon nicht mehr.

Es gibt keine neuen kritischen Punkte wie in registry schreiben, oder
Zugriff auf irgendwelche geschützten Dateien.

Wie kann man sowas noch nachverfolgen? Bin momentan ratlos
Das komische auf einem anderen WTS 2003 funktioniert es...da ist allerdings auch schon SP2 drauf (der andere hat SP1)

Unix-Tom

Startet nicht ist die Sprache von einem Dau.
Wenn Du ein Programm geschrieben hast gehe ich davon aus das DU das nicht bist.
Also bitte etwas genauer. Jedes Programm, welches nicht startet macht irgendetwas.
Schau auch mal in das Windowslog.

Martin Richter

Remote Debugging ist immer eine Option um Fehler zu suchen.

Wenn InitInstance angelaufen wird, was gibt InitInstance zurück?

BTW: Nach InitInistance wird CWinApp::Run aufgerufen.

Martin Richter schrieb:

Remote Debugging ist immer eine Option um Fehler zu suchen.

Wenn InitInstance angelaufen wird, was gibt InitInstance zurück?

BTW: Nach InitInistance wird CWinApp::Run aufgerufen.

Sorry war nur unter Zeitdruck als ich meinen Beitrag geschrieben habe.
Das mit "geht nicht" höre ich leider in unserer Hotline den ganzen Tag...
man möchte den Leuten für die verschwendete Zeit am liebsten eins in die Fresse hauen

Das mit CWinApp::Run: Da gibt es doch afaik nur eine einfache Deklaration oder?

virtual int Run();

InitInstance kehrt mit false zurück fürchte ich. Hab das Projekt leider jetzt
nicht hier. DoModal() wird demnach wohl fehlschlagen, nur warum?

Genaueres kann ich morgen im Büro sagen. Es hätte ja durchaus sein können,
dass 2003Server mit SP1 dafür bekannt ist zu Problemen zu führen.
Alles was ich nachträglich eingebaut habe sind zwei Dialoge und eine SMTP-Klasse
via winsock. Das wird jedoch alles wunderbar kompiliert, läuft auch sonst
auf allen Systemen soweit, und ist im Programmablauf nicht direkt beim
Programmstart eingebunden, sondern erst dynamisch über eine dll zur Laufzeit.

Auf einem Rechner wo ich Admin bin unter Win2003 (allerdings mit SP2) gibt es
keine Probleme. Ich teste es morgen nochmal mit eingeschränkten Userrechten.

foodax

Variant schrieb:

Alles was ich nachträglich eingebaut habe sind zwei Dialoge und eine SMTP-Klasse
via winsock. Das wird jedoch alles wunderbar kompiliert, läuft auch sonst
auf allen Systemen soweit, und ist im Programmablauf nicht direkt beim
Programmstart eingebunden, sondern erst dynamisch über eine dll zur Laufzeit.

Ein Schuss ins Blaue: "Deaktiviere mal die Datenausführungsverhinderung" bzw. "Data Execution Protection" im 2003er. Wenn ich SMTP und Sockets lese, könnte das für Windows unter bestimmten Randbedinungen als gefährtlich eingestuft werden.

Diese "Feature" hat mich auch schon zwei Tage auf einem 2003er gekostet.

Gruss
foo

Martin Richter

Wenn InitInstance false zurückgibt, wird Dein Programm beendet.
Wie wäre es mal mit debuggen?

CWinApp::Run hat auch eine Implementierung und nicht nur eine Deklaration! Und Du hast sogar den Sourcecode der MFC wo Du nachlesen kannst, was das tut.

Deine Infos sind einfach nicht ausreichend. Was ist das für ein Programm? SDI/MDI/Dialog?

Nur mal so am Rande:
Wenn das Mainwindow im InitInstance erzeugt UND geschlossen wird, und WM_QUIT bereits ausgeliefert wurde, dann kann man kein weiteres Fenster mehr erzeugen... Also auch nicht DoModal für irgendeinen Dialog ausführen, oder eine MessageBox.

Es ist eine dialogbasierte Anwendung. InitInstance gibt mir true zurück.

~Mal am Rande: Dumme Frage sicherlich, aber wie kann ich auf einem PC
debuggen, auf dem das Visual Studio nicht drauf ist?
~

Leider kann ich als normaler User nicht an die Einstellungen für die Daten-
ausführungsverhinderung ran. Admin ist erst morgen wieder da. Kann man dazu
irgendwas aus der Registry ableiten? Dort habe ich zumindest lesend Zugriff...

Martin Richter

Dialogbasierend und InitInsitace gibt TRUE zurück. Das ist Unfug, sofern DoModal in InitInstance aufgerufen wird. Ist das so?

Remote Debugging für welche Version?
VC 6: http://www.mpdvc.de/artikel/RemoteDebugging.htm
VS-200x: http://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx

Visual Stduio 2008. Vielleicht hilft der Code der InitInstance mir zu helfen?
Datenausführungsverhinderung kann ich ausschließen, da es mit selbiger auf
einem anderen Win2003-Rechner dennoch funktioniert.

Ich schaue mir jetzt das Remotedebugging an. Danke Martin.

BOOL CtestfallApp::InitInstance()
{
	InitCommonControlsEx();

	CWinAppEx::InitInstance();

	AfxEnableControlContainer();

	SetRegistryKey(_T("Vom lokalen Anwendungs-Assistenten generierte Anwendungen"));

	CtestfallDlg dlg;
	m_pMainWnd = &dlg;

//=====================================================================
//hier steigt das Programm aus und beendet sich  
//kein eintrag im ereignislog von windows
//die messagebox kommt noch, danach ist schluß.
MessageBox(0,"Test",0,0);

	INT_PTR nResponse = dlg.DoModal();
	if (nResponse == IDOK)
	{
		// TODO: Fügen Sie hier Code ein, um das Schließen des
		//  Dialogfelds über "OK" zu steuern
	}
	else if (nResponse == IDCANCEL)
	{
		// TODO: Fügen Sie hier Code ein, um das Schließen des
		//  Dialogfelds über "Abbrechen" zu steuern
	}

	// Da das Dialogfeld geschlossen wurde, FALSE zurückliefern, sodass wir die
	//  Anwendung verlassen, anstatt das Nachrichtensystem der Anwendung zu starten.
	return FALSE;
}

Martin Richter

Schon mal versucht, nach DoModal ein GetLastError einzubauen und zu prüfen was passiert?

Das Programm gibt bei GetLastError zurück, dass der Vorgang
erfolgreich beendet wurde.
Nachdem ich GetLastError eingebunden habe erscheinen plötzlich auch
die nachfolgenden Messageboxen, die sonst nie angezeigt wurden.

INT_PTR nResponse = dlg.DoModal();

nResponse liefert was anderes zurück als IDOK oder IDCANCEL und zwar "-1".
Danach beendet das Programm.

Ich muss dazu sagen, dass ich gelgentlich folgende Compilermeldung erhalte.....:

Fehler 1 Fehler "31" wurde von "C:\Programme\Microsoft SDKs\Windows\v6.0A\bin\mt.exe" zurückgegeben. Projekt Testfall

Kurzer Nachtrag:

An int value that specifies the value of the nResult parameter that was passed to the CDialog::EndDialog member function, which is used to close the dialog box. The return value is –1 if the function could not create the dialog box, or IDABORT if some other error occurred, in which case the Output window will contain error information from GetLastError.

GetLastError kann ich ja danach gar net mehr aufrufen, da dass Programm beendet wird. Oder wie ist das gemeint? Wie soll ich für

CtestfallDlg dlg;
m_pMainWnd = &dlg;

GetLastError abfragen, wenn das Programm danach sofort geschlossen wird?

sri

Möglicherweise ein Fehler beim Einbinden des Manifests?

Martin Richter

Hast Du evtl. ein RTF Control drauf oder ein ActiveX Control das nicht registriert ist.

Und sicher kannst Du GetLastErrornoch aufrufen. Das Programmstürzt doh nicht ab. Es beendet doch kontrolliert.

Hallo Martin,

ich mache es sicher falsch mit GetLastError:

CtestfallDlg dlg; 
m_pMainWnd = &dlg;

INT_PTR nResponse = dlg.DoModal();

	LPVOID lpMsgBuf;

	if (!FormatMessage( 
		FORMAT_MESSAGE_ALLOCATE_BUFFER | 
		FORMAT_MESSAGE_FROM_SYSTEM | 
		FORMAT_MESSAGE_IGNORE_INSERTS,
		NULL,
		GetLastError(),
		MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), // Default language
		(LPTSTR) &lpMsgBuf,
		0,
		NULL ))
	{
	}
	MessageBox( 0,(LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION );
	LocalFree( lpMsgBuf );

	if (nResponse == IDOK)
	{
		MessageBox(0,"OK!",0,0);

	}
	else if (nResponse == IDCANCEL)
	{
		MessageBox(0,"CANCEL!",0,0);

	}else
	{
		CString g;
		g.Format("%i",nResponse);
		MessageBox(0,g,0,0);
	//rückgabewert ist "-1"
	}

Martin Richter

Du hast ein Problem!
Die Messageboxen werden nicht mehr angezeigt, wenn WM_QUIT gepostet wurde.

Kommentiere mal die Zeile:

m_pMainWnd = &dlg;

in Deinem InitInstance testweise aus.

Ich habe es testweise dann mal auskommentiert. Am Laufverhalten ändert sich jedoch nichts.

Unser Admin schaut sich momentan mit dem Prozessmonitor von sysinternals das
genauer an. Was ich soweit gesehen habe ist, dass NAME NOT FOUND öfter auftaucht
für:

TestfallDEU.dll oder auch TestfallLOC.dll bzw. Testfall.exe.2.manifest

Und noch einige weitere Dateien, die ich nichtmal kenne

Habe eben dann eine manifest-Datei neben die EXE kopiert. Auch keine Änderung.
Die Testfall.exe selbst hat ein manifest eingebettet bekommen:

In "RT_MANIFEST" unter Nr "1" steht folgendes:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Testfall"
type="win32"
/>
<description>Beschreibung</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>

Martin Richter

Das hat damit gar nichts zu tun.

Könntet Ihr nicht etwas strukturierter vorgehen?
Euer Problem ist doch warum der Diaog nicht angezeigt wird?
Also wäre der nächste Schritt zu prüfen ob überhaupt WM_INITDIALOG versendet wird...

Was wird denn nun von GetLastError ausgegeben, wenn DoModal mit -1 beendet wird?
Du hast zwar Code eingabut der etwas anzeigt, aber nicht geschrieben was passiert!

Aktueller Stand ist:

Bis OnInitDialog komme ich gar nicht (das entspricht doch WM_INITDIALOG oder?). Das Programm wirft schon nicht mal mehr
die MessageBox nach:

//in InitInstance()
INT_PTR nResponse = dlg.DoModal();
MessageBox("nach dlg.DoModal()");

Auch mein GetLastError wird an der Stelle wo jetzt die MessageBox
zu sehen ist nicht mehr verarbeitet.