Ich müh' mich schon seit Wochen mit diesem Problem herum; komme aber nicht weiter. Es ist mir auch nicht gelunden, den Kern des Problems herauszukristallisieren. Das Ganze isr recht obskur und ich werde vermutlich Mühe haben, das Problem klar zu schildern. Also sorry im voraus. Die Software, die zickt, ist eine 32bit Applikation. Laeuft seit Jahren bei verschiedenen Kunden. Normalerweise öffnet innerhalb des Programs eine Form so in 1 bis max. 2 Sekunden. Ist die OS aber Windows 7, dauert es bei manchen Kunden min. 10 Sekunden. Manchmal 12. Kunde A hat Windows 7 Home Basic. Die Form öffnet in 2 Sekunden. Kunde B hat Windows 7 Professional 64 Bit. Die Form öffnet in 2 Sekunden. Kunde C hat Windows 7 Home Premium 64 Bit. Die Form öffnet in 12 Sekunden. Dem Kunden C habe ich mit VMWare Windows 7 Professional 64 bit installiert: und die Form öffnete in 2 Sekunden. Daraufhin hat der Kunde 140 USD hingeblaettert und einen Upgrade vorgenommen. Resultat: die Form öffnet weiterhin in 12 Sekunden. Mit VMWare dauert es weiterhin 2 Sekunden. Hardware: i7 / 1.7 GHz / 6 GB Ram Hat jemand für dieses Verhalten eine plausible Erklaerung?
Gast
#2152024
Was ist das fuer eine Form? Selbstgeschriebene Anwendung? Zeigen andere Programme das gleiche Verhalten? -> Falls nein, scheint es kein Problem mit der Grafik zu sein. Was macht die Anwendung; welche Ressourcen braucht sie, fuehrt sie z. B. einen Netzwerkzugriff aus?
Gast
#2152025
Also eine Ferndiagnose ist ja immer schwierig. Aber was mir sofort durch den Kopf schoss, als ich deinen Beitrag las, ist, dass bei den Kunden, bei denen es 10/12sec dauert, noch andere Tasks laufen, die das Starten der erwähnten App verzögern. Hast du das mal individuell bei jedem Kunden gecheckt? -> Taskmanager?
Ja, das Program habe ich geschrieben. Visual FoxPro. Also alle anderen Programme laufen normal. Netzwerkzugriff auf MySQL-Server geht ohne Verzögerung vonstatten. Und wenn die Form dann endlich offen ist, geht auch der Rest (zum Teil recht komplizierte Berechnungen) wie gewohnt zügig. Beim Kunden C habe ich heute die Taskbar/Performance betrachtet: der Rechner langweilt sich zu Tode. Max. Auslastung war glaube ich 8% Interessant ist ja, dass in einer virtuellen Umgebung die gewohnte Performance erreicht wird.
Gast
#2152077
Irgendein Virenscanner oder so der die Datei erstmal unter die Lupe nimmt?
Jep; Deaktivierung des Virusprogramms hat nichts gebracht.
Gast
#2152089
Falls viele Elemente auf der Form sind, könnte die graka einfach scheiße sein ;D
Ja, es sind sehr viele Elemente. Wenn es aber die GK waere, dann müsste es auch in der virtuellen Umgebungen zu dieser Verzögerung kommen. Tut es aber nicht.
Gast
#2152113
wenn es dein code ist, was hindert dich dran einfach mal eine log datei zu mit zeiten zu erstellen? Das öffnen einen Forms sind auch auch nur funktionsaufrufe. Oder einfach mal ein Debugger laufen zu lassen - kann denn heute wirklich keiner mehr systematisch Fehler suchen?
@Peter Habe ich schon alles gemacht. Dort wo es zum Aussetzer kommt, werden hunderte von Controlls initialisiert ( ... okay, vielleicht ein klein wenig übertrieben). Zum Teil von mir, zum Teil von VFP. Da kann ich beim besten Willen kein Log führen.
Gast
#2152122
Mehmet Kendi schrieb: > Zum Teil von mir, zum Teil von VFP. > Da kann ich beim besten Willen kein Log führen. und warum nicht? Logdatei können auch schon mal ein paar MB gross sein - man könnte auch schlau rangehen erstmal bei der Hälfte ein log schreiben. Dann weiss man schon mal in welchem Teil das Problem liegt. Dann wieder die Hälfte und dann hat man es schon. Von selber wird sich das Problem nicht lösen
>Habe ich schon alles gemacht. Dort wo es zum Aussetzer kommt, werden >hunderte von Controlls initialisiert ( ... okay, vielleicht ein klein >wenig übertrieben). Zum Teil von mir, zum Teil von VFP. >Da kann ich beim besten Willen kein Log führen. Was glaubst Du, wie es andere Softwarehersteller machen: die programmieren aktivierbare Log-/Trace-Logik mit rein für den Fall, daß es irgendwo klemmt.
@Peter Wie gesagt, in jede Init Methode jedes Elements eine Zeiterfassung zu schreiben, wenn auch nur nach der Guttenberg-Methode, ist sehr schwer realisierbar. Desweiteren habe ich z.Bsp. mit meinem Notebook (Win7 Prof) dieses Problem nicht. Ich müsste es also bei einem Kunden testen ... und dort kann ich schlecht sagen "mach mal Pause für ein paar Stunden, ich brauch deinen Rechner".
Gast
#2152149
Mehmet Kendi schrieb: > Wie gesagt, in jede Init Methode jedes Elements eine Zeiterfassung zu > schreiben, wenn auch nur nach der Guttenberg-Methode, ist sehr schwer > realisierbar. da schreibt man sich ein kleines script was das erledigt, kann doch wohl nicht so schwer sein! Wenn es objektorientiert ist dann sind doch wo alle Controlls von einer Klasse abgeleitet, dann reicht es sogar dort das log zu schreiben. Das ist auch kein aufwand für den Kunden, er soll dann einfach früh das Programm starten und dir dann das log zuschicken.
>Desweiteren habe ich z.Bsp. mit meinem Notebook (Win7 Prof) dieses >Problem nicht. Ich müsste es also bei einem Kunden testen ... und dort >kann ich schlecht sagen "mach mal Pause für ein paar Stunden, ich brauch >deinen Rechner". Dann mußt Du eben weiter rumrätseln ...
Gast
#2152916
Graka-Treiber auf dem neuesten Stand? http://www.tomshardware.de/WDM-GDI-WDDM-ATI-Radeon,testberichte-240480.html Ich würde einfach versuchen die Anzahl der Controls auf der Form zu reduzieren
Gast
#2152925
Hm, also vermutlich doch Probleme mit der Grafik (Karte, Treiber). Kurze Google-Suche ergab, dass sogar eine Logging-API fuer FoxPro existiert: http://spacefold.com/articles/Log4Fox.aspx (Natuerlich wuerde fuer Deine "Debugging"-Zwecke auch eine Ausgabe der Zeiten, die jeder Initialisierungsbefehl benoetigt, reichen). Bau sowas mal ein, indem Du nach jedem Initialisierungsblock eine entsprechende Meldung ausgibst.
Gast
#2152927
Vielleicht auch ein Problem beim Netzzugriff (DNS Namensauflösung). Evtl. steht der DNS Server per ISDN ausserhalb.
bluppdidupp schrieb: > Graka-Treiber auf dem neuesten Stand? Patrick schrieb: > Hm, also vermutlich doch Probleme mit der Grafik (Karte, Treiber). Ich hatte geschrieben, dass in virtueller Umgebung mit derselben OS es keine Verzögerung gibt. thomas schrieb: > Vielleicht auch ein Problem beim Netzzugriff Ich hatte geschrieben, ".. Netzwerkzugriff auf MySQL-Server geht ohne Verzögerung vonstatten." Wenn's in VMWare dasselbe Verhalten waere, würde ich sagen: "es liegt an VFP". Aber dort laeuft es völlig normal und das kapier ich nicht.
Gast
#2153304
Mehmet Kendi schrieb: > Ich hatte geschrieben, dass in virtueller Umgebung mit derselben OS es > keine Verzögerung gibt. Hatte ich gelesen. Die VM simuliert eine GraKa, so dass es durchaus ein Problem irgendwo zwischen Software und GraKa sein kann. Logge mal die Zeiten waehrend des Form-Initialisierens mit und grenze so den Fehler ein; alles andere macht keinen Sinn.
Mehmet Kendi schrieb: > bluppdidupp schrieb: >> Graka-Treiber auf dem neuesten Stand? > Patrick schrieb: >> Hm, also vermutlich doch Probleme mit der Grafik (Karte, Treiber). > > Ich hatte geschrieben, dass in virtueller Umgebung mit derselben OS es > keine Verzögerung gibt. Und? In der virtuellen Umgebung hast du mit Sicherheit auch eine virtuelle (und damit komplett andere) Grafikkarte. Und das "Weiterreichen" der Bilddaten an den realen Treiber kann dann über komplett andere Befehle laufen, wie das direkte "Malen".
Patrick schrieb: > Hatte ich gelesen. Die VM simuliert eine GraKa, so dass es durchaus ein > Problem irgendwo zwischen Software und GraKa sein kann. Das wusste ich nicht.
Also irgendwie leuchtet mir das mit der GK nicht ein. Schliesslich ist es ja nicht ein einzelner Kunde, der dieses Problem sein eigen nennt; sondern mehrere. Und sie haben alle verschiedene Notebooks. Hauptsaechlich Asus und Toshiba. Und bei allen soll die GK problematisch sein?? Das einzige was sie gemeinsam haben: Windows 7. Meist Home Premium.
Gast
#2153594
Mehmet Kendi schrieb: > Also irgendwie leuchtet mir das mit der GK nicht ein. das halte ich auch für sehr unwahrscheinlich. Bau ein Log ein und Brichte uns von den Fehler.
Mich hatte mal ein Problem in den Wahnsinn getrieben, wo ein Dateibrowser ewig lang brauchte, bis das Fenster aufging. Komischerweise immer dann, wenn ich der letzte im Büro war. Das Ende vom Lied: Ich hatte ein Netzwerklaufwerk auf dem Rechner meines Kollegen gemountet, welcher ausgeschaltet wurde, wenn der Kollege nach Hause ging... "Mein CD-Laufwerk ist hin, kannst Du mir Deins freigeben?"
Gast
#2153918
Hat es eventuell etwas mit den Energiesparfunktionen im BIOS zu tun? Hatte mal was ähnliches. Die PCs liefen unter XP einwandfrei bis Win7 auf die Geräte installiert wurde. Unter Win 7 ruckelten alle Fenster beim verschieben massiv, bis hin zum Absturz. (Bios und Treiber waren auf dem neusten Stand.) Am Schluss war es eine Einstellung in den Energieoptionen im BIOS. Bei mir half damals der Eintrag: "Energieverwaltung bei Inaktivität" von "Erweitert" auf "Normal" zu setzen. Vielleicht mal schauen, ob es im BIOS auch eine Option in der Richtung gibt.
Eddy Current schrieb: > Ich hatte ein Netzwerklaufwerk auf dem Rechner ... gemountet" Ne, gemountet ist (zumindest bei einem Rechner bin ich mir da ganz sicher) nichts. Desweiteren ist das Problem nicht zeitlich begrenzt. Markus schrieb: > Vielleicht mal schauen, ob es im BIOS auch eine Option in der Richtung > gibt. Werde ich am Montag machen. Und wohl oder übel in alle verdaechtigen Init Methoden ein paar Log-Zeilen hinzufügen.
Hallo, so ein Problem kenn ich auch. Bei mir sind es Green-Festplatten, die sehr schnell in den Standby gehen. Wenn Du jetzt massiv Controls instanzierst und Win 7 erst die Platten mit der Auslagerungsdatei hochfahren muss, dann kommt das mit 10 Sekunden gut hin. Evtl. verhindert auch VM, dass die Platten in den Standyby fallen, was dann das Verhalten komplett erklären würde. CU, Crazy
Okay, werde ich am Montag auch testen.
Also ich war diese Woche mehrere Kunden besuchen. War zwar nicht sehr ergiebig das Ganze, weil einige mit denen ich ein kameradschaftliches Verhaeltnis habe, entweder im Ausland weilten, oder nicht anwesend waren. Ich konnte also nicht wie geplant "rutsch mal zur Seite" sagen. Bios-Einstellung und ob die Festplatten erst hochfahren müssen konnte ich deshalb nicht kontrollieren. Werde also naechste Woche nochmals zu denen hinpilgern. Ich habe nun doch einen eigenen Log-Mechanismus eingebaut. Beim Aufruf einer Form geht Vfp wie folgt vor: Form.Load() Initialisierung der Controls Form.Init() Form.Show() Die Wartezeit erfolgt nach Form.Load und der Initialisierung des 1. Controls. Was Vfp dort macht konnte ich bis anhin nicht ausfindig machen. Desweiteren: mit Home Basic 64bit gibt es keine Probleme. Desweiteren: in einer Firma gibt es 2 identische Notebooks (Toshiba) mit Home Premium 64bit als OS. Der eine öffnet die Form in 2 Sekunden. Der andere in 12 Sekunden.
Gast
#2160825
Mehmet Kendi schrieb: > Was Vfp dort macht konnte ich bis anhin nicht ausfindig machen. du könntest ja mal mit dem Processmonitor schauen was in der Zeit passiert.
Peter, danke für den Tipp. Ganz vergessen, dass es ja ein solches Tool gibt.
Schon der Wahnsinn, was da so alles im Hintergrund sich zu Wort meldet. Wegen dieser Flut habe ich den Filter auf mein Programm gesetzt. Die Summe der durations ergibt so rund 30ms. Wenn ich aber die Differenz der Spalte TimeOfDay berechne, komme ich bei 2 Zeilen auf 3 Sekunden und 2,5 Sekunden. Also da ist irgendwas, das Sand ins Getriebe streut. Aber das schaue ich mir naechste Woche beim Kunden an. So mit Fernwartung geht das schlecht. Peter, nochmals Danke für den Tipp.
Gast
#2161743
Mehmet Kendi schrieb: > Desweiteren: in einer Firma gibt es 2 identische Notebooks (Toshiba) mit > Home Premium 64bit als OS. Der eine öffnet die Form in 2 Sekunden. Der > andere in 12 Sekunden. Wenn die Möglichkeit besteht, würde ich möglichst mit diesen zwei identischen Geräten versuchen die Unterschiede festzustellen (wie BIOS Konfig und Version, Systemdateien, Systemeinstellungen etc.).
Hast du schon mal mit Procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645) das Verhalten des Programms analysiert? Damit kannst du u.a. sehen, wie lange Datei-, Registry- und ich glaube auch API-Zugriffe dauern und ob sie fehlgeschlagen sind. Edit: Wichtig - die Anzeige auf deinen Prozess beschränken, sonst wird die Kiste aufgrund des Logging schon sehr langsam
Lieber Chris, diesen Tipp hat der Peter schon gegeben (4 Beitraege weiter oben) ....
Kopfkratz .... Also ich war wieder beim Kunden. ProcessMonitor gestartet; "capture events" disabled. Mein Program gestartet. "Capture events" enabled und gleich die Form gestartet. Nach rund 12 - 13 Sekunden, nachdem die Form offen war: "capture events" disabled und als csv exportiert. Alles in allem waren es rund 380.000 Events. Da OpenCalc sich weigerte soviele Zeilen zu importieren, musste ich auf MySQL ausweichen. Nachdem ich also die Werte in eine Table importiert hatte, ergab sich folgendes Bild. Start der Form 11:00:33 Ende der Form 11:00:53 Gesamt-Dauer ca. 30ms. Dann mit "ORDER BY duration DESC" geschaut, wer am meisten konsumiert: SearchIndexer.exe: 11:00:33 Dauer: 3,9 sec SearchIndexer.exe: 11:00:37 Dauer: 1,0 sec SearchIndexer.exe: 11:00:38 Dauer: 4,9 sec SearchIndexer.exe: 11:00:43 Dauer: 4,9 sec SearchIndexer.exe: 11:00:48 Dauer: 2,8 sec SearchIndexer.exe: 11:00:51 Dauer: 2,1 sec Mit einem Schmunzeln auf den Lippen: Start -> Control Panel -> Programs -> Turn Windows features on or off ... ... Kopfkratz ... IndexService ist gar nicht aktiv. Vermutlich verwechsle ich da was. Help!
Gast
#2168810
ich würde den filter nur auf den Pogramm festlegen, was geht dich denn bei der suche der SearchIndexer.exe an? Du willst doch wissen was dein Programm in dem Moment macht und nicht was noch gleichzeitig läuft. Wenn du dann feststellt das das öffnen einer Datei zu lange dauert dann kann man suchen warum das so ist. Aber du bist noch beim 1. Schritt - du willst erstmal wissen was genau so lange dauert und dafür ist nur dein Programm interressant.
Gast
#2168813
> Mit einem Schmunzeln auf den Lippen: Start -> Control Panel -> Programs > -> Turn Windows features on or off ... > ... Kopfkratz ... > IndexService ist gar nicht aktiv. > Vermutlich verwechsle ich da was. Help! Google zufolge ist das ein Dienst, guck mal unter Ausführen --> services.msc ob sich da irgendein Search-, Index-,... Dienst verbirgt. Einen Versuch ist es wert (aber nicht vergessen die Änderungen rückgängig zu machen wenns nicht hilft!).
Peter, das hatte ich ja schon gemacht. Das Oeffnen der Form dauer alles in allem 30ms. Mehr konsumiert mein Program nicht.
Ahnungsloser, hatte ich schon gemacht. "Windows Search" kam mir der Sache am naechsten; aber ein Stop dieses Services hat nichts gebracht.
Gast
#2168834
Mehmet Kendi schrieb: > Ahnungsloser, hatte ich schon gemacht. "Windows Search" kam mir der > Sache am naechsten; aber ein Stop dieses Services hat nichts gebracht. Tja, dann... Die Holzhammermethode ist ein 'dir /s' und ein 'rename', auf eigene Gefahr!
Gast
#2168905
Mehmet Kendi schrieb: > Peter, das hatte ich ja schon gemacht. Das Oeffnen der Form dauer alles > in allem 30ms. Mehr konsumiert mein Program nicht. dann musst du dort weiter suchen, es muss zum schluss ein punkt wo das Programm wartest. Wenn du es in deinem Programm nicht findest, dann schreib ein Testprogramm. Wenn der Computer sonst ohne Probleme läuft, dann liegt es nicht an Indexdienst, bios oder sotwas. Es liegt an DEINER software dir irgendetwas macht und auf einem Timeout wartet.
Gast
#2168973
Searchindexer ist die Windows-Suche ("Windows Search") und nicht der
Indexdienst (der ist durch die Windows-Suche in aktuellen
Windows-Versionen ersetzt worden)
...würde mich aber wundern wenn der tatsächlich Schuld wäre ;D
Jetzt wird's esoterisch! Ich habe ein ziemlich gutes Notebook von Sony das ich aber sehr selten benutze. Einem meiner problematischen Kunden, der ein Notebook von Asus hat (auch nicht von schlechten Eltern) machte ich deshalb den Vorschlag: Notebook-Tausch. Denn mit meinem Notebook öffnet die Form innerhalb von 2 Sekunden. Der Kunde war natürlich sofort einverstanden. Ich gab ihn also mein Notebook zu Testzwecken. Sein Urteil: super! Also habe ich mein Notebook neu aufgesetzt, seine Daten aufgespielt ... und zum Spass sagte ich ihm noch: "Ich müsste jetzt aber schön lachen, wenn jetzt bei Ihnen die Form wieder mit Verzögerung öffnet." Als dann der Rechner zum ersten mal gestartet wurde, stand der Kunde von seinem Schreibtisch auf und bot mir den Platz an: "Mache Sie mal ..." Aber da war nichts. Die Form öffnete innerhalb von 1 - 2 Sekunden. Mein Kunde erleichtert: "Oleeee!" Er nahm wieder seinen Platz ein ... und seitdem öffnet die Form wieder mit Verzögerung. Dem irritierten Kunden konnte ich nur irritiert sagen: "Ich glaube mit Ihrer Chemie stimmt was nicht."
Mehmet Kendi schrieb: > Ich glaube mit > Ihrer Chemie stimmt was nicht http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug ;)
Gast
#2198073
Mehmet Kendi schrieb: > Er nahm wieder seinen Platz ein ... und seitdem öffnet die Form wieder > mit Verzögerung. > Dem irritierten Kunden konnte ich nur irritiert sagen: "Ich glaube mit > Ihrer Chemie stimmt was nicht." scheinbar versucht du immer noch das Problem bei windows zu suchen. Aber DEINE Anwendung öffnet langsam. Selbst wenn es an Windows liegt musst du den konkreten API aufruf bei dir finden um das Problem zu lösen.
Gast
#2198110
@Memet ich habe das gleiche Problem mit gleicher und unterschiedlicher Software, alles nicht selbst geschrieben, sondern zwischen Freeware und Kommerzieller Software auf allen Win7 Rechner. Das Problem existiert übrigens nicht erst seit Win7. Das gab es schon zu WIN2000 -> Xp Zeiten, aber die Unterschiede da wurden nicht so drastisch wahrgenommen, weil die Verzögerung nur im einstelligen Sekundenbereich lag. Wir sind gerade dabei, alles was Win7 ist wegzuwerfen und zu XP zurückzukehren. Alle die das nicht können, müssen mit VM-Ware oder am Terminalserver arbeiten. Da das Problem schon mit der Win-Grundinstallation beginnt, und selbst Applikationen aus dem Betriebssystem selbst betrifft, lange bevor an Netzwerk, oder externe Geräte zu denken ist, kann davon ausgegangen werden, dass es ein BS-Internes Problem ist.
Gast
#2198118
tex schrieb: tex schrieb: > ich habe das gleiche Problem mit gleicher und unterschiedlicher > Software, alles nicht selbst geschrieben, sondern zwischen Freeware und > Kommerzieller Software auf allen Win7 Rechner. und diese Software kann wohl keine Fehler enthalten? Hier hat Mehmet sogar den Vorteil das es seine Software ist damit ist die Fehlersuche einfacher. > Da das Problem schon mit der Win-Grundinstallation beginnt, und selbst > Applikationen aus dem Betriebssystem selbst betrifft, lange bevor an > Netzwerk, oder externe Geräte zu denken ist, kann davon ausgegangen > werden, dass es ein BS-Internes Problem ist. komisch, ich habe eine Zeitlang über 500 PC mit Windows2000 und XP betreut. Dort wurden auch verschiedenen Progamme genutzt und ich habe diesen Problem noch nie gesehen. Selber habe ich auch Windows2000, XP und Win7 im Einsatz und entwickle dafür Software auch dort ist diesen Problem noch nie aufgetreten. Ich halte es immer noch für ein Sofwarefehler in der Anwendung. Selbst wenn das Problem im Betriebssystem steckt muss man für die Diagnose wissen an welcher stelle das System hängt. Es muss also igend ein API aufruf länger dauern und diesen muss man finden. Dann kann man damit mal bei google suchen. Aber solange man nicht mal ein Hinweiss hat wo es hängt macht es überhaupt keinen sinn an verschienden PC zu testen weil man damit NIE die ursache findet.
Lieber Peter der Zweite. Ich verstehe Deinen Unmut, aber ich kann beim besten Willen nicht noch tiefer debuggen. Der Haenger ist zwischen Form.Load und dem ersten Controll.Init() Was dort passiert konnte ich nicht ausfindig machen.
Gast
#2198135
Nachtrag: Hier mal ein Beispiel einer Anwenung die unter XP langsam und unter Windows2000 schnell ging. Borland Interbase (ibserver.exe). Nach ewiger suchen stelle sich heraus das es nicht am BS lag sondern an der anzahl der CPUs. Die Anwendung hat ein Problem mit 2CPUs. Es gibt keinen Fehler es läuft nur extrem langsam. Eventuell mal vesuchen der Anwendung eine CPU zuzuordnen oder gleich dem Betriessystem nur eine CPU zur Verfügung stellen.
Gast
#2198142
Mehmet Kendi schrieb: > Der Haenger ist zwischen Form.Load und dem ersten > Controll.Init() > Was dort passiert konnte ich nicht ausfindig machen. und warum nicht? jeden etwicklungsumgebung hat die Möglichkeit auf ASM weiter zu debuggen. Oder ist es nur eine Scriptsprache? Wenn es aber bei anderen Formularen nicht der Fall ist, dann muss du so lange das Formular abspecken bis es geht. Ich weiss selber das sotwas sehr zeitraubend ist, aber mir macht so ein Rätzel spass. Kann man deien Anwendung einfach mal so auf jeden PC laufen lassen, wenn ja könnte ich es bei mir mal testen.
Peter II schrieb: > auf ASM weiter zu debuggen. Oder ist es nur eine Scriptsprache? Hust. ASM und PC ... also die Liga, in der ich spiele, ist viel weiter unten :)
Gast
#2198362
Mehmet Kendi schrieb: > Peter II schrieb: > >> auf ASM weiter zu debuggen. Oder ist es nur eine Scriptsprache? > Hust. ASM und PC ... also die Liga, in der ich spiele, ist viel weiter > unten :) es geht ja nur ums debuggen, ich schreibe auch kein ASM mehr auf dem PC. Aber beim Debuggen geht es manchmal nicht ohne, weil der debugger sonst nicht in alle funktionsaufrufe reingeht.
Kannst fürs erste auch mal mit adplus (von MS windbg bzw SDK) den Stack ausdumpen lassen, während das Programm gerade hängt. Dann weiste schon mal, was für Funktionen da gerade im Stack sind - könnte dann einen Hinweis ergeben.
Sorry, dass ich die Leiche wieder ans Tageslicht zerre. Das Problem konnte durch Zufall gelöst werden, als ein Kunde mich anrief und reklamierte, dass er so um die 30 - 45 Sekunden warten müsse, bis die Form öffne. Da ich gerade in der Naehe war, ging ich zu ihm hin. Und tatsaechlich hatte er nicht übertrieben. Nach etwas Fischen im Trüben stellte sich heraus, dass auf dem Rechner eine Unmenge von Druckern installiert war, die alle nicht gebraucht wurden. Ich habe sie alle bis auf die aktuell Benutze deinstalliert - und seitdem öffnen die Formen ohne Verzögerung.
Hallo, Mehmet Kendi schrieb: > Sorry, dass ich die Leiche wieder ans Tageslicht zerre. > Das Problem konnte durch Zufall gelöst werden, als ein Kunde mich anrief > und reklamierte, dass er so um die 30 - 45 Sekunden warten müsse, bis > die Form öffne. Das "Happy End" darf man meiner Meinung nach auch nach längerer Zeit noch "posten". Mit freundlichen Grüßen Guido
Gast
#3848314
Mehmet Kendi schrieb: > Ich habe sie alle bis auf die aktuell Benutze deinstalliert - und > seitdem öffnen die Formen ohne Verzögerung. Bleibt natürlich die Frage, wieso dein Programm durch die Anzahl der installierten Drucker untolerierbar ausgebremst wird, andere Programme aber offensichtlich nicht.
Wolfgang A. schrieb: > Bleibt natürlich die Frage, wieso dein Programm durch die Anzahl der > installierten Drucker untolerierbar ausgebremst wird, andere Programme > aber offensichtlich nicht. Vermutlich ist es ein "Feature" der Runtime-Lib von Visual FoxPro.
Gast
#3848774
Jo, vermutlich fragt da irgendwas von FoxPro den Druckerstatus ab und irgendwelche Druckertreiber reagieren da nicht zeitnah drauf (insbesondere bei Netzwerkdruckern gut möglich) ;D
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.