Sorry, but...
Sorry, but...
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 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.
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 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...
As always, let me know if you can reproduce the issue. For the minidumps, try searching your drives for *.dmp files.
psguru
PrestoSoft
PrestoSoft
Re: Sorry, but...
*.dmp?
I searched for *minidump*.*!
I'll repeat the search, sorry.
I searched for *minidump*.*!
I'll repeat the search, sorry.
Re: Sorry, but...
No *.dmp files anywhere.
Re: Sorry, but...
So maybe EDP cannot create the minidump for some reason (you are on XP after all). So our hope is a reproducible scenario.
psguru
PrestoSoft
PrestoSoft
Re: Sorry, but...
XP? Nope! Now I'm talking about Windows 10.
N.B. No *.dmp on XP either.
EDP 12.0.0.13 64
On XP I haven't, so it's not really a wonder to have such a problem, but on 10?In that system I have a "standard" registered mailer
N.B. No *.dmp on XP either.
-
- Expert Member
- Posts: 108
- Joined: Sun May 02, 2010 12:00 pm
- Location: Edinburgh
Re: Sorry, but...
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
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...
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.
-
- Expert Member
- Posts: 108
- Joined: Sun May 02, 2010 12:00 pm
- Location: Edinburgh
Re: Sorry, but...
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.
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...
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).The whole thing is handled by the EDP exception manager, or so I think.
psguru
PrestoSoft
PrestoSoft
Re: Sorry, but...
Yeah, that's what I meant.JeremyNicoll wrote: ↑Tue Jun 08, 2021 1:37 pmit might have said it was "searching for a solution"...
That's also my experience!JeremyNicoll wrote: ↑Tue Jun 08, 2021 1:37 pmsomething that in my experience has never helped with any application I've ever used.