Page 1 of 1

Sorry, but...

Posted: Fri Jun 04, 2021 1:19 pm
by MSpagni
EDP 12.0.0.13 64
I was comparing a couple of text files using manual sych and editing them when EDP crashed.
I have no idea on how to reproduce the problem so this is food for another day.

I got the usual :wink: dialog asking to send you some data and the minidump.
In that system I have a "standard" registered mailer, so I answered "yes".
No mail, no messages, no minidump either. Simply, EDP disappeared.

Once again: where do the minidumps go?
It seems the problem is not correlated to the mailer or the OS.

Re: Sorry, but...

Posted: Fri Jun 04, 2021 1:22 pm
by psguru
As always, let me know if you can reproduce the issue. For the minidumps, try searching your drives for *.dmp files.

Re: Sorry, but...

Posted: Fri Jun 04, 2021 1:28 pm
by MSpagni
*.dmp?
I searched for *minidump*.*!

I'll repeat the search, sorry.

Re: Sorry, but...

Posted: Mon Jun 07, 2021 11:22 am
by MSpagni
No *.dmp files anywhere.

Re: Sorry, but...

Posted: Mon Jun 07, 2021 11:34 am
by psguru
So maybe EDP cannot create the minidump for some reason (you are on XP after all). So our hope is a reproducible scenario.

Re: Sorry, but...

Posted: Mon Jun 07, 2021 10:21 pm
by MSpagni
XP? Nope! Now I'm talking about Windows 10.
EDP 12.0.0.13 64
In that system I have a "standard" registered mailer
On XP I haven't, so it's not really a wonder to have such a problem, but on 10?

N.B. No *.dmp on XP either.

Re: Sorry, but...

Posted: Tue Jun 08, 2021 12:50 am
by JeremyNicoll
I don't know what a "standard registered mailer" is, but I can't see how that would determine whether a dump gets taken or not.


A while back, in Windows 8.1, I went through the process described at

https://docs.microsoft.com/en-us/window ... mode-dumps

to ensure that any application that crashes here will generate a dump (and not a mini one, either). The notes I have say that
these days the default (since normal users will have no idea what to do with a dump) is that none are taken.


You can define all-application defaults, in

HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps

or application-specific settings (eg for "pqr.exe") in

HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\pqr.exe

One of the settings is the location into which the dumps will be written. The default is %LOCALAPPDATA%\CrashDumps
but on my system I have changed that to %PUBLIC%\CrashDumps so that dumps taken by either my day-to-day userid
or my admin id will end up in the same place. Provided one isn't worried (eg on a multi-user system) by having dumps
from different users in a place where anyone can read them, the public location is (I think) a better idea.


Note that dumping system processes place their dumps, by design, elsewhere:

- system services' dumps end up in: %WINDIR%\System32\Config\SystemProfile

- network and local services end up in:
%WINDIR%\ServiceProfiles\LocalService and %WINDIR%\ServiceProfiles\NetworkService

Several times per day I scan the whole of %WINDIR% looking for any unexpected dumps - of course I only expect them
to be in these specific locations (plus the system dump location) but not-altogether trusting MS I prefer to look in the
whole of %WINDIR%.


The process where Windows sometimes tells you that something has crashed and that it's "checking for solutions" is
also configurable, in broad terms. Application developers can also use an API to have information from their apps
sent to MS who then collate it (ie from all the people whose app is crashing) and pass it back to the developers.
More info on that at: https://docs.microsoft.com/en-us/window ... -reporting


Also ...

Whether whole-system dumps (ie after a BSOD) get created is controlled (at least in Win 8.1) from Control Panel -
System - Advanced System Settings - Startup-and-recovery - Settings. Apart from always wrting an eventlog record,
I have "Write debugging information" set to "Complete memory dump" and the location is the default one, ie:
"%SystemRoot%\MEMORY.DMP".

This is what one needs if a BSOD dump is to be any use (eg to an anti-malware vendor). When the dump is taken,
Windows puts data into the pagefile (and for that those MUST be on the %WINDIR% drive), then next time one
boots the system that data is copied out of the pagefile into the MEMORY.DMP file. It follows that for this to work
one's pagefile needs to be big enough - in fact it needs to be bigger than the amount of RAM in your machine. More
info on that at: https://support.microsoft.com/en-gb/kb/969028

Re: Sorry, but...

Posted: Tue Jun 08, 2021 12:12 pm
by MSpagni
JeremyNicoll wrote: Tue Jun 08, 2021 12:50 am I don't know what a "standard registered mailer" is
Very easy: is the one that opens up when you click on a "mailto:..." URL. Usually it is Outlook or Thunderbird or...
In my XP I removed outlook and I use Pegasus, that's not registered, for the mails, so if I click on a "mailto:..." URL nothing happens.

All that you write is true, but in my case the minidump is not generated by a windows BSOD and the dialog don't asks me to inform Microsoft. The whole thing is handled by the EDP exception manager, or so I think.

Re: Sorry, but...

Posted: Tue Jun 08, 2021 1:37 pm
by JeremyNicoll
OK, but the mailer thing is a side-issue. If a dump exists on your machine you should be able to find it, compress it (eg with 7-zip) then attach it to a mail or put it somewhere in the cloud and send Prestosoft its URL.

I only wrote the info about collecting BSOD dumps for completeness. Most people have no idea how to do it.

You said "the dialog don't asks me to inform Microsoft". Nothing I wrote was intended to say that anything would ask you to contact MS. /If/ the WER interface was involved, it might have said it was "searching for a solution"... something that in my experience has never helped with any application I've ever used.

For an application crash like you're seeing, it's possible that EDP itself should handle creation of a dump. But maybe the dialog you mention, asking you to locate and send the minidump to Prestosoft, assumes that Windows will have taken the dump. If that's so, you will need to set up application dump processing yourself because the default on Win 10 is that dumps are not produced. You need either to turn them on for all applications, or explicitly for the EDP executable.

Re: Sorry, but...

Posted: Tue Jun 08, 2021 2:16 pm
by psguru
The whole thing is handled by the EDP exception manager, or so I think.
Yes, it is. The fact that there's no .dmp file created may mean the application is in such a bad state that it unable to do so (although this s rare).

Re: Sorry, but...

Posted: Wed Jun 09, 2021 5:50 am
by MSpagni
JeremyNicoll wrote: Tue Jun 08, 2021 1:37 pmit might have said it was "searching for a solution"...
Yeah, that's what I meant.
JeremyNicoll wrote: Tue Jun 08, 2021 1:37 pmsomething that in my experience has never helped with any application I've ever used.
That's also my experience! :lol: