Issue in WIN-8 64-bit (Divide by zero exception)

There is a simple answer that will not help you. There is a bug in the application.

It is difficult to tell the reason without debugging the application or without having the source code. Say, one of the versions works with lengths of the language related text. Say, the author of other language support forgot to translate some text and the length of the missing (translated) text is zero by default. Say, something is bigger or smaller in the other language and some parts of memory is not initialized or is overwritten by mistake. Say, the other locale uses a different format of anything converted to a text, and spoils some calculation somehow. There can be tons of reasons.

Please check link
http://www.codeproject.com/Answers/824919/Issue-in-WIN-bit-Divide-by-zero-exception?cmt=681232#answer1
 
for more details.

as per the C++ standard there's no exception defined for divide by zero. As far as I know under such conditions behaviour is undefined.
So I wouldn't be surprised with the behaviour you are seeing.

I'm quoting Stroustrup here in "The Design and Evolution of C++" (Addison Wesley, 1994) :


"low-level events, such as arithmetic overflows and divide by zero, are assumed to be handled by a dedicated lower-level mechanism rather than by exceptions. This enables C++ to match the behaviour of other languages when it comes to arithmetic. It also avoids the problems that occur on heavily pipelined architectures where events such as divide by zero are asynchronous."


Also Section 5.6 of the C++ standard also mentions this

If the second operand of / or % is zero the behavior is undefined

a likely reason for the issue is that the locale changed to numeric separators, hence period and comma characters would exchange their meaning for numbers in string format what might lead to a conversion failure.

to test whether that is the reason you may change the locale to german and check. you also could check for string to number conversions in the code and whether the result of such a conversion was used as divisor or in a modulo operation.

if it fails with the german locale as well, it still could be a conversion issue as the os is English. you may try with a German win-64 then.

Sara

as per the C++ standard there's no exception defined for divide by zero.

win32 exceptions contain
- c0000094 integer division by zero
- c000008e Floating-point division by zero

Sara

win32 exceptions contain
- c0000094 integer division by zero
- c000008e Floating-point division by zero

these are win32 exceptions. I didn't know that the C++ standard was Windows specific

what's defined in the standard is this

class logic_error;
class domain_error;
class invalid_argument;
class length_error;
class out_of_range;
class runtime_error;
class range_error;
class overflow_error;
class underflow_error;


Do we see a divide-by-zero exception here? Or perhaps Stroustrup is wrong in what he said...

a likely reason for the issue is that the locale changed to numeric separators, hence period and comma characters would exchange their meaning for numbers in string format
 you also could check for string to number conversions in the code and whether the result of such a conversion was used as divisor or in a modulo operation.

The OP has not mentioned any string conversions.

win api is an ansi c library. when using windows api, win32 exceptions may be thrown regardless whether the c++ standard defined them or not.

The point is that the C++ standard doesn't require an exception to be generated when a div by zero is attempted. Behavior is undefined by the standard.

The root cause may be due to string formats or various other reasons but for a Div by Zero the C++ standard doesn't define behavior and that's something Subrat ALSO needs to know.

the win api was made long before c++ standard and so I fail to see the point. c++ allows to use standard c libraries and the exceptions thrown are not c++ exceptions but SEH exceptions. though both are called 'exceptions' a c++ try-catch would not be able to catch them beside proprietary compiler options were set to enable it. the error here was reported by the operation system in the event viewer and not by the application what is an indication that the code either didn't try to catch the exception first-case or was not enabled to catch SEH exceptions.

anyhow, there is no reason to have doubts that the exceptions were thrown and that a divide-by-zero case happened after changing the locale.

Sara