Unhandled exception 0xC000041D

I get this 'unhandled exception' randomly. Meaning, about one in every 5-10 starts of the program. Running under SDBG, I see the error, but am very confused as to why it would be happening. The error is in a initialization routine called by my %mv handler, where a TYPE is being initialized (programmatically) after being ALLOCATE'd.

Code is too long to post here.

Any idea how to find out which 'unhandled exception' this is, or what the meaning might be?

A possible clue. Is it permissible to be creating a %cw (for user directed output) and try to write to it? Stated another way, if one is creating a child window that contains a %cw format code, should one refrain from writing possible output to this window in response to a %mv event? The program was responding to a %ud not being detected (user data appears to not be attached to the parent window), so the output was to tell me that this had occurred (which it never should have).

I ask this because I know how asynchronous things can get with windows being created and initialized, and suspect this is clue may be the actual reason.

I am concerned that the %ud used to attach the user data to the window did not pass the value. I will attempt to circumvent this error reporting another way if I can (therefore a different problem). Is it possible that I get a %mv for a child window for which there is no attached 'user data'?

If C000041D is a memory address, this is 3,221,226,525, which would be a high address for /32 SDBG ? This looks like a stack problem to me, although the 1 in 5-10 starts may say I am wrong. I would try to move any local/automatic arrays to the heap and check all ALLOCATE status and try to confirm where it is occurring. You indicate you have tracked it in SDBG, so my comments may be again wrong. (I always see stack problems!) Are you using /debug or /check, as /debug will reduce these overheads. ALLOCATE with /check in /32 did have some problems (might have been fixed in Ver 8) Why not SDBG64 ? as most of these types of errors would disappear. Once you get use to INTEGER(7) /64, it is much easier (unless you are importing .dll's)

C000041D probably means (from https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--1000-1299-):

*ERROR_SERVICE_REQUEST_TIMEOUT

1053 (0x41D)

The service did not respond to the start or control request in a timely fashion. *

So... what does that mean? Good question, I don't know. Does the exception happen when you run the program without SDBG? If it doesn't then you could just try ignoring the exception. You can do this by editing sdbg.ini and adding the line:

IgnoreException-0=c000041d

On my machine sdbg.ini is located at:

C:\Users\Robert\AppData\Local\VirtualStore\Windows\sdbg.ini

Robert and John, all good answers.

John, it was difficult enough to get this old legacy code working in 32-bit. Extended this 40 year old code to 64-bit is definitely not on my immediate horizon! Much of the legacy code uses (and relies on) /SAVE, so stack utilization is minimal, save for the system/Salford routines that might use it. I have experienced some FTN95 memory allocation issues that are puzzling and frustrating, but those have been identified and steps taken to minimize or eliminate issues. I also have some users who are running 32-bit Windows OS's and don't want them to be excluded. It is difficult enough to maintain a Production implementation and a Development implementation simultaneously, when the two instantiations have to be kept physically separated before I add on a third and fourth with 64-bit!

Further Background: I was starting the program with no indication of the reason for the ending. I observed that there was about a 2-4 second delay from the invocation to the ending, and the Splash Screen did not display, so that limited the possible code to a smaller set. I have a common exit point handling routine, so I know it never got there. It had to be ending due to some exception or exit point that was outside of my code.

These were NOT SDBG runs. It happened both on /CHECKMATE and /RELEASE compilations, although less so on /CHECKMATE. This was a hint.

I ran the /RELEASE program in SDBG (my first time running SDBG actually) just to see what the reason for the abnormal termination was, if possible, and that's the info I posted. It took a number of tries (more than 'normal') to get the problem to throw the exception. The reason made no sense when I looked at where in the execution stream it occurred. It was my %sc handler. Initialization of an allocated data item to zero (single element)? Nah, can't be....

Robert, the information you posted I was never able to find. Lots of reference to this specific exception, but no real explanation. So, many thanks for a better description. It makes sense after the fact; I put in a 3 second delay between building the child windows and the creation of the main window. Dozens of attempts to get the program to fail after making that change were not successful. My thinking is if there is something regarding the creation of a child with %cw, and I was trying to 'write' to the default (%cw attached) unit while the final window was being built (that was where the exception was thrown), this might cause an asynchronous condition that SOMETIMES causes the crash.

So, is the 'problem' solved? Probably not, but it is likely to be at such a low occurrence that it is 'acceptable'. As a former aerospace engineer, I still look for root cause in any failure (even my household projects). Alas, I shall probably never see it.

The reason for this longer e-mail is to assist someone else who might experience the same behavior, and can take similar steps to eliminate the problem. I experienced this same asynchronous behavior in some 'C' Windows code a number of years ago, where I had expected (from the documentation) that State 'A' would be complete before State 'B' would be started. I found out that this was NOT the case all the time. It made the coding more cumbersome, but also prevented 'odd' behaviors and crashes.

Bill,

Your problems are fascinating. If you need to make sure that activity A is complete before you start activity B, then it seems logical that Activity A has to report that it has completed before you dare start B. If these were different programs, you could use Windows messaging, but if they are just different routines in your code perhaps the message-passing could be simpler.

At least if you get the same error every time, you know that the problem is (eventually) solvable, it's those occasional errors that are difficult to pin down.

I'm always astonished at how slowly MS Office applications start up, especially relative to my own programs compiled with FTN95, so perhaps the programmers at MS make them wait around. It's what your startup splash screen hides, I suppose. Or maybe the average programmer at MS HQ likes things to start slowly so that there's time to nip outside for a spliff before they have to do some real work (and which would explain away some of the more bizarre things in Windows)!

Eddie

The delay resembles the file opening problem we had a few years ago. There was another mention of this recently. Perhaps a MS KBxxx or FTN95 regression has brought it back. I would say, if the report is a memory address, then it looks like memory is limited in your 32 bit application, especially if run on a 32-bit OS. You also mentioned it happened both on /CHECKMATE and /RELEASE compilations. Have you tried /DEBUG ?

The delay resembles the file opening problem we had a few years ago.

I thought that too.

All,

I'll try to address the comments properly. Thanks for taking the time.

Using /DEBUG: No, I haven't tried that. Since it happens with both my development /CHECKMATE and with the delivery /RELEASE, I could add that in. I have seen cases where (and it has been alluded to here) where the code generated for /CHECKMATE and /RELEASE give differing results. Not in the accuracy of the answer, but in the execution and throwing of different exceptions. I am hesitant to use this as a tool since the exception is 'Unknown Exception' and there's no other information.

Windows asynchronous activities are always a pain, regardless if they are in 'C' code or FTN95. The reason this showed up was my first full window is created with an attached pointer (using %ud). However, the user data pointer was not actually set (returned a value of zero). Not usable, and would cause a crash with an Access Violation if used. So, a slightly different path is taken in the code to handle this, and that is when the C000041D gets generated. I think I understand the 'why' behind the error in the different path, just not the 'why' behind the %ud not being usable. With the delay, the %ud appears to be always working. The %ud and the attached data structure is the equivalent (in my application) of a semaphore, without the overhead of an actual messaging call. Because passing a message uses the same message handler that is 'causing' the problem in the first place.

John and Robert:I am curious about the file opening problem a few years back. I don't remember what that was or the resolution of it. From what I can see in my application, I don't think this would have an effect, but I am curious! Do you have a reference?

Eddie: The splash screen is displayed because that's what users expect to happen, quickly, when they start an application. I know I appreciate it since sometimes I thought I double-clicked something and it didn't start up!

John,

I don't see how one may take C000041D as an address. The thread title is 'Unhandled exception 0xC000041D'.

I suspect that the OS provides a skeleton exception handler for cases where the exception (1) is not one for which Windows provides a full handler, (2) is raised, and (3) the user's code or the compiler's runtime has not provided a handler.

In effect, the skeleton handler is saying, 'I am being asked to handle an exception that I don't know how to handle, so I am giving you a message and terminating the process'.

mecej4, I think you are exactly correct in your assessment of the exception under discussion. It is as if the OS is saying 'Beats the heck out of me as to what has actually happened, but I do know that continuing is in no one's best interest, so Bye Bye!'.

Kind of like in the old days with parity checks on memory. Without a specific handler that can deal with the issue and not corrupt something else, the OS knows something bad has happened and cannot proceed.

In my 're-host' effort of the software to FTN95 and windows, I had a lot of really 'bad' exceptions thrown. I discovered that after about 8 to 12 of them that the OS got 'wonky', and I'd need to reboot. I suspect that simply logging out and back in would clear the exceptions, but I was unwilling to use a smaller hammer. I still see that today with other applications that will occasionally crash and leave the system in an odd state.