Text editing crash

Eudora 7.1.0.9 had been working reasonably well for me under Windows 7 Pro x64 for many years.
In 2019, I performed an in-place upgrade to Windows 10.

My install has had a bug ever since. It happens when I type or edit the body text
inside a new email or reply. The first hint that it is about to crash is that typing
just makes whitespace. If there was text there, it will just advance the cursor over
existing text like overstrike mode.

At this point Eudora will crash. My edits generally disappear if I let it crash.

If I stop when the typing becomes invisible, ask it to save my changes,
and close Eudora and restart, then my edits are generally saved and I can reopen that email and continue.

One way that often causes it is to "reply all" to an email with a larger
body text, make a few changes that insert text. So some kind of memory leak? Another clue may be that if I stop right away, the "save" dialog is one
style. If I wait a little longer, I get a slightly different "save" dialog with larger text and a different font.

My Eudora is installed at C:\Eudora. My old exceptions log says:

Eudora.exe caused an EXCEPTION_ACCESS_VIOLATION in module
MFC71.DLL at 0023:7C158431, Ordinal2234()+0015 byte(s)

and (from 2019) the last bit of the call stack was:

0023:7C16E1B8 (0x00531134 0x00000000 0x00000203 0x00000000) MFC71.DLL, Ordinal1209()+0059 byte(s)
0023:7C16E1F6 (0x00531134 0x00000000 0x00000203 0x00000000) MFC71.DLL, Ordinal1209()+0121 byte(s)
0023:745848EB (0x7C16E1BD 0x00000000 0x00531134 0x00000000) USER32.dll, AddClipboardFormatListener()+0075 byte(s)
0023:7456613C (0x7C16E1BD 0x00000000 0x00000000 0x00000000) USER32.dll, CallWindowProcW()+2860 byte(s)
0023:7456528E (0x00000001 0x00000000 0x00756920 0x00000000) USER32.dll, DispatchMessageW()+0558 byte(s)
0023:74569291 (0x004007EA 0x00000000 0x00756918 0x00000000) USER32.dll, IsDialogMessageW()+0257 byte(s)
0023:7458102E (0x004007EA 0x00000000 0x00756918 0x00000000) USER32.dll, IsDialogMessage()+0078 byte(s)
0023:7C153E61 (0x00000000 0x00000000 0x00000000 0x00000000) MFC71.DLL, Ordinal3920()+0026 byte(s)

My MFC71.DLL in C:\Eudora is version 7.10.6030.0, dated 12/6/2011.
My MFC71.DLL in C:\Windows\SysWOW64 is version 7.10.3077.0, dated 10/17/2003.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 2, 2023 at 2:14:20 PM UTC-4, jfo...@gmail.com wrote:

Text editing crash

Eudora 7.1.0.9 had been working reasonably well for me under Windows 7 Pro x64 for many years.
In 2019, I performed an in-place upgrade to Windows 10.

My install has had a bug ever since. It happens when I type or edit the body text
inside a new email or reply. The first hint that it is about to crash is that typing
just makes whitespace. If there was text there, it will just advance the cursor over
existing text like overstrike mode.

At this point Eudora will crash. My edits generally disappear if I let it crash.

If I stop when the typing becomes invisible, ask it to save my changes,
and close Eudora and restart, then my edits are generally saved and I can reopen that email and continue.

One way that often causes it is to "reply all" to an email with a larger body text, make a few changes that insert text. So some kind of memory leak? Another clue may be that if I stop right away, the "save" dialog is one style. If I wait a little longer, I get a slightly different "save" dialog with larger text and a different font.

My Eudora is installed at C:\Eudora. My old exceptions log says:

Eudora.exe caused an EXCEPTION_ACCESS_VIOLATION in module
MFC71.DLL at 0023:7C158431, Ordinal2234()+0015 byte(s)

and (from 2019) the last bit of the call stack was:

0023:7C16E1B8 (0x00531134 0x00000000 0x00000203 0x00000000) MFC71.DLL, Ordinal1209()+0059 byte(s)
0023:7C16E1F6 (0x00531134 0x00000000 0x00000203 0x00000000) MFC71.DLL, Ordinal1209()+0121 byte(s)
0023:745848EB (0x7C16E1BD 0x00000000 0x00531134 0x00000000) USER32.dll, AddClipboardFormatListener()+0075 byte(s)
0023:7456613C (0x7C16E1BD 0x00000000 0x00000000 0x00000000) USER32.dll, CallWindowProcW()+2860 byte(s)
0023:7456528E (0x00000001 0x00000000 0x00756920 0x00000000) USER32.dll, DispatchMessageW()+0558 byte(s)
0023:74569291 (0x004007EA 0x00000000 0x00756918 0x00000000) USER32.dll, IsDialogMessageW()+0257 byte(s)
0023:7458102E (0x004007EA 0x00000000 0x00756918 0x00000000) USER32.dll, IsDialogMessage()+0078 byte(s)
0023:7C153E61 (0x00000000 0x00000000 0x00000000 0x00000000) MFC71.DLL, Ordinal3920()+0026 byte(s)

My MFC71.DLL in C:\Eudora is version 7.10.6030.0, dated 12/6/2011.
My MFC71.DLL in C:\Windows\SysWOW64 is version 7.10.3077.0, dated 10/17/2003.

I'm running under Win10 without substantial issues, other than UI things I don't care for. I don't know off the top of my head, but I know the MFC DLL file causes trouble for a lot of programs. Is MFC71.DLL the right version for Eudora?

It rather sucks that the main reason for an OS, is to be able to run programs as the hardware is updated. Seems the OS is less compatible than the hardware.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, 2 March 2023 at 23:04:47 UTC, gnuarm.del...@gmail.com wrote:

On Thursday, March 2, 2023 at 2:14:20 PM UTC-4, jfo...@gmail.com wrote:

Text editing crash

Eudora 7.1.0.9 had been working reasonably well for me under Windows 7 Pro x64 for many years.
In 2019, I performed an in-place upgrade to Windows 10.

My install has had a bug ever since. It happens when I type or edit the body text
inside a new email or reply. The first hint that it is about to crash is that typing
just makes whitespace. If there was text there, it will just advance the cursor over
existing text like overstrike mode.

At this point Eudora will crash. My edits generally disappear if I let it crash.

If I stop when the typing becomes invisible, ask it to save my changes, and close Eudora and restart, then my edits are generally saved and I can reopen that email and continue.

One way that often causes it is to "reply all" to an email with a larger body text, make a few changes that insert text. So some kind of memory leak?
Another clue may be that if I stop right away, the "save" dialog is one style. If I wait a little longer, I get a slightly different "save" dialog with larger text and a different font.

My Eudora is installed at C:\Eudora. My old exceptions log says:

Eudora.exe caused an EXCEPTION_ACCESS_VIOLATION in module
MFC71.DLL at 0023:7C158431, Ordinal2234()+0015 byte(s)

and (from 2019) the last bit of the call stack was:

0023:7C16E1B8 (0x00531134 0x00000000 0x00000203 0x00000000) MFC71.DLL, Ordinal1209()+0059 byte(s)
0023:7C16E1F6 (0x00531134 0x00000000 0x00000203 0x00000000) MFC71.DLL, Ordinal1209()+0121 byte(s)
0023:745848EB (0x7C16E1BD 0x00000000 0x00531134 0x00000000) USER32.dll, AddClipboardFormatListener()+0075 byte(s)
0023:7456613C (0x7C16E1BD 0x00000000 0x00000000 0x00000000) USER32.dll, CallWindowProcW()+2860 byte(s)
0023:7456528E (0x00000001 0x00000000 0x00756920 0x00000000) USER32.dll, DispatchMessageW()+0558 byte(s)
0023:74569291 (0x004007EA 0x00000000 0x00756918 0x00000000) USER32.dll, IsDialogMessageW()+0257 byte(s)
0023:7458102E (0x004007EA 0x00000000 0x00756918 0x00000000) USER32.dll, IsDialogMessage()+0078 byte(s)
0023:7C153E61 (0x00000000 0x00000000 0x00000000 0x00000000) MFC71.DLL, Ordinal3920()+0026 byte(s)

My MFC71.DLL in C:\Eudora is version 7.10.6030.0, dated 12/6/2011.
My MFC71.DLL in C:\Windows\SysWOW64 is version 7.10.3077.0, dated 10/17/2003.

I'm running under Win10 without substantial issues, other than UI things I don't care for. I don't know off the top of my head, but I know the MFC DLL file causes trouble for a lot of programs. Is MFC71.DLL the right version for Eudora?

It rather sucks that the main reason for an OS, is to be able to run programs as the hardware is updated. Seems the OS is less compatible than the hardware.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

Both of my MFC71.DLL files in those locations are version 7.10.3077.0.
Why you have an apparently newer version in your Eudora program files folder is a bit of a mystery!
I would rename that file MFC71.DLL.OLD (with Eudora closed of course) and then copy the file from the SysWOW64 folder to the Eudora program folder so both files are the same. This may fix it, as Eudora is probably trying to use the file in its program
folder, and it may not be compatible.
HTH. Cheers, Dave.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, March 3, 2023 at 6:33:09 AM UTC-6, DaveH2 wrote:

Both of my MFC71.DLL files in those locations are version 7.10.3077.0.
Why you have an apparently newer version in your Eudora program files folder is a bit of a mystery!
I would rename that file MFC71.DLL.OLD (with Eudora closed of course) and then copy the file from the SysWOW64 folder to the Eudora program folder so both files are the same. This may fix it, as Eudora is probably trying to use the file in its program

folder, and it may not be compatible.

Yes, I had once tried to swap the various MFC DLLs to cure the problem. I can't help but wonder if my environment has been corrupted by some past code development or other installations. Mine are now:

Eudora:
03/18/2003 09:12 PM 1,047,552 mfc71u-last.dll 7.10.3077.0
03/18/2003 09:20 PM 1,060,864 mfc71-last.dll 7.10.3077.0
12/06/2011 05:37 PM 1,058,600 MFC71u.dll 7.10.6030.0
12/06/2011 05:37 PM 1,066,280 MFC71.dll 7.10.6030.0

SysWow64:
10/17/2003 11:44 AM 1,060,864 mfc71.dll 7.10.3077.0
02/20/2004 03:47 PM 1,047,552 mfc71u.dll 7.10.3077.0

What file sizes and dates do you have?

Which other DLLs might be the problem?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, 3 March 2023 at 17:51:52 UTC, jfo...@gmail.com wrote:

On Friday, March 3, 2023 at 6:33:09 AM UTC-6, DaveH2 wrote:

Both of my MFC71.DLL files in those locations are version 7.10.3077.0.
Why you have an apparently newer version in your Eudora program files folder is a bit of a mystery!
I would rename that file MFC71.DLL.OLD (with Eudora closed of course) and then copy the file from the SysWOW64 folder to the Eudora program folder so both files are the same. This may fix it, as Eudora is probably trying to use the file in its

program folder, and it may not be compatible.

Yes, I had once tried to swap the various MFC DLLs to cure the problem. I can't help but wonder if my environment has been corrupted by some past code development or other installations. Mine are now:

Eudora:
03/18/2003 09:12 PM 1,047,552 mfc71u-last.dll 7.10.3077.0
03/18/2003 09:20 PM 1,060,864 mfc71-last.dll 7.10.3077.0
12/06/2011 05:37 PM 1,058,600 MFC71u.dll 7.10.6030.0
12/06/2011 05:37 PM 1,066,280 MFC71.dll 7.10.6030.0

SysWow64:
10/17/2003 11:44 AM 1,060,864 mfc71.dll 7.10.3077.0
02/20/2004 03:47 PM 1,047,552 mfc71u.dll 7.10.3077.0

What file sizes and dates do you have?

Which other DLLs might be the problem?

I don't have any 7.10.6030.0 versions. I would replace both MFC71.dll and MFC71u.dll in the Eudora program files folder with the 7.10.3077.0 versions.
I think the 'last' suffix on the other two files indicates that they are the last (previous) versions of the files, which have been replaced by something.
This may well have caused the problem, and the only way of knowing is to effectively roll them back to the original versions.
If you just rename the 7.10.6030.0 versions, rather than deleting them, you can easily restore them if necessary.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 4 March 2023 at 13:31:44 UTC, jfo...@gmail.com wrote:

On Friday, March 3, 2023 at 5:43:42 PM UTC-6, DaveH2 wrote:

I think the 'last' suffix on the other two files indicates that they are the last (previous) versions of the files, which have been replaced by something.

Yes, that was my note to my future self.

This may well have caused the problem, and the only way of knowing is to effectively roll them back to the original versions. If you just rename the 7.10.6030.0 versions, rather than deleting them, you can easily restore them if necessary.

I removed MFC71.DLL and MFC71U.DLL from the Eudora folder, assuming it would be happy with
the ones in SysWow. Eudora ran, the bug was still there.

I've tried reading the DMP files to get a clue...

STACK_TEXT:
0019f8a0 0045bea0 0019f8d8 06a3b608 00000014 MFC71!CDC::SelectObject+0x8 WARNING: Stack unwind information not available. Following frames may be wrong.
0019f8f8 0046501b 006da108 06a3b608 06a3b608 Eudora+0x5bea0
0019f90c 7c1ac5a9 00000014 00000000 00000000 Eudora+0x6501b
0019f96c 7c1ac639 00000000 00020db2 00000014 MFC71!AfxCallWndProc+0x91
[...]
FAULTING_SOURCE_LINE_NUMBER: 239
FAULTING_SOURCE_CODE:
No source found for 'f:\vs70builds\6030\vc\mfcatl\ship\atlmfc\src\mfc\wingdi.cpp'

SYMBOL_NAME: MFC71!CDC::SelectObject+8
MODULE_NAME: MFC71
IMAGE_NAME: MFC71.dll

FAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005_MFC71.dll!CDC::SelectObject

So maybe https://github.com/mirror/winscp/blob/master/libs/mfc/source/wingdi.cpp ...

CGdiObject* CDC::SelectStockObject(int nIndex)
{
ASSERT(m_hDC != NULL);

HGDIOBJ hObject = ::GetStockObject(nIndex);
HGDIOBJ hOldObj = NULL;

ASSERT(hObject != NULL);
if (m_hDC != m_hAttribDC)
hOldObj = ::SelectObject(m_hDC, hObject); <===
if (m_hAttribDC != NULL)
hOldObj = ::SelectObject(m_hAttribDC, hObject);
return CGdiObject::FromHandle(hOldObj);
}

None of that means much to me I'm afraid!
I would try copying the MFC71 files in the SysWOW64 folder into the Eudora folder anyway, just in case Eudora isn't using them correctly. Remember that Eudora is very old now, and may not completely play nicely with modern operating systems, especially
64 bit.
If that doesn't change anything, the only thing I can suggest is to do a reinstall of Eudora, if you haven't already tried that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, March 3, 2023 at 5:43:42 PM UTC-6, DaveH2 wrote:

I think the 'last' suffix on the other two files indicates that they are the last (previous) versions of the files, which have been replaced by something.

Yes, that was my note to my future self.

This may well have caused the problem, and the only way of knowing is to effectively roll them back to the original versions. If you just rename the 7.10.6030.0 versions, rather than deleting them, you can easily restore them if necessary.

I removed MFC71.DLL and MFC71U.DLL from the Eudora folder, assuming it would be happy with
the ones in SysWow. Eudora ran, the bug was still there.

I've tried reading the DMP files to get a clue...

STACK_TEXT:
0019f8a0 0045bea0 0019f8d8 06a3b608 00000014 MFC71!CDC::SelectObject+0x8 WARNING: Stack unwind information not available. Following frames may be wrong. 0019f8f8 0046501b 006da108 06a3b608 06a3b608 Eudora+0x5bea0
0019f90c 7c1ac5a9 00000014 00000000 00000000 Eudora+0x6501b
0019f96c 7c1ac639 00000000 00020db2 00000014 MFC71!AfxCallWndProc+0x91 [...]
FAULTING_SOURCE_LINE_NUMBER: 239
FAULTING_SOURCE_CODE:
No source found for 'f:\vs70builds\6030\vc\mfcatl\ship\atlmfc\src\mfc\wingdi.cpp'

SYMBOL_NAME: MFC71!CDC::SelectObject+8
MODULE_NAME: MFC71
IMAGE_NAME: MFC71.dll

FAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005_MFC71.dll!CDC::SelectObject

So maybe https://github.com/mirror/winscp/blob/master/libs/mfc/source/wingdi.cpp ...

CGdiObject* CDC::SelectStockObject(int nIndex)
{
ASSERT(m_hDC != NULL);

HGDIOBJ hObject = ::GetStockObject(nIndex);
HGDIOBJ hOldObj = NULL;

ASSERT(hObject != NULL);
if (m_hDC != m_hAttribDC)
hOldObj = ::SelectObject(m_hDC, hObject); <===
if (m_hAttribDC != NULL)
hOldObj = ::SelectObject(m_hAttribDC, hObject);
return CGdiObject::FromHandle(hOldObj);
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 4, 2023 at 8:31:44 AM UTC-5, jfo...@gmail.com wrote:

On Friday, March 3, 2023 at 5:43:42 PM UTC-6, DaveH2 wrote:

I think the 'last' suffix on the other two files indicates that they are the last (previous) versions of the files, which have been replaced by something.

Yes, that was my note to my future self.

This may well have caused the problem, and the only way of knowing is to effectively roll them back to the original versions. If you just rename the 7.10.6030.0 versions, rather than deleting them, you can easily restore them if necessary.

I removed MFC71.DLL and MFC71U.DLL from the Eudora folder, assuming it would be happy with
the ones in SysWow. Eudora ran, the bug was still there.

I've tried reading the DMP files to get a clue...

STACK_TEXT:
0019f8a0 0045bea0 0019f8d8 06a3b608 00000014 MFC71!CDC::SelectObject+0x8 WARNING: Stack unwind information not available. Following frames may be wrong.
0019f8f8 0046501b 006da108 06a3b608 06a3b608 Eudora+0x5bea0
0019f90c 7c1ac5a9 00000014 00000000 00000000 Eudora+0x6501b
0019f96c 7c1ac639 00000000 00020db2 00000014 MFC71!AfxCallWndProc+0x91
[...]
FAULTING_SOURCE_LINE_NUMBER: 239
FAULTING_SOURCE_CODE:
No source found for 'f:\vs70builds\6030\vc\mfcatl\ship\atlmfc\src\mfc\wingdi.cpp'

SYMBOL_NAME: MFC71!CDC::SelectObject+8
MODULE_NAME: MFC71
IMAGE_NAME: MFC71.dll

FAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005_MFC71.dll!CDC::SelectObject

So maybe https://github.com/mirror/winscp/blob/master/libs/mfc/source/wingdi.cpp ...

CGdiObject* CDC::SelectStockObject(int nIndex)
{
ASSERT(m_hDC != NULL);

HGDIOBJ hObject = ::GetStockObject(nIndex);
HGDIOBJ hOldObj = NULL;

ASSERT(hObject != NULL);
if (m_hDC != m_hAttribDC)
hOldObj = ::SelectObject(m_hDC, hObject); <===
if (m_hAttribDC != NULL)
hOldObj = ::SelectObject(m_hAttribDC, hObject);
return CGdiObject::FromHandle(hOldObj);
}

The problem with MFC DLLs, is that you often need the appropriate version, rather than the latest version. I thought this had been discussed here several times.

Does anyone know the correct version for Eudora? I don't know how to get that info.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)