Windows error 0x000000EF, 239

Detailed Error Information

CRITICAL_PROCESS_DIED[1]

This is a Blue Screen of Death stop code. More information is available in the Knowledge Base article Bug Check 0xEF: CRITICAL_PROCESS_DIED.

HRESULT analysis[2]

This is probably not the correct interpretation of this error. The Win32 error above is more likely to indicate the actual problem.
FlagsSeveritySuccess

This code indicates success, rather than an error. This may not be the correct interpretation of this code, or possibly the program is handling errors incorrectly.

Reserved (R)false
OriginMicrosoft
NTSTATUSfalse
Reserved (X)false
FacilityCode0 (0x000)
NameFACILITY_NULL[2][3]
DescriptionThe default facility code.[2][3]
Error Code239 (0x00ef)

Possible solutions

5

Exchange 2016 on Windows Server 2012 BSoD

exchange
vmware-esxi
windows-server-2012-r2
exchange-2016

Your storage system is failing or too slow to keep up. If IO has been stalled for too long, Exchange thinks that storage is dead and kills Wininit to force hard reset.

See https://technet.microsoft.com/en-us/library/ff625233.aspx and scroll to the end. It's the same for 2013 and 2016.

In some cases, the entire storage stack may be affected by the hang, making it impossible to write failure events to the crimson channel or any other area of the Windows Event Log. ESE also monitors the crimson channel by verifying that the event log can be written to. If writing to the event log fails for a long period of time, MSExchangeRepl intentionally causes a bugcheck of Windows by terminating wininit.exe. When the operating system I/O is hung, the system is obviously unable to write any ESE events to the event log.

I have experienced it firsthand when using Windows Server Backup to backup Exchange. When backup begins, it will do consistency check on all databases in parallel. This caused Exchange to BSoD after a few minutes when storage dropped out.

First solution is to disable ATS heartbeat to storage array https://kb.vmware.com/kb/2113956

Text is too long to copy but TL;DR: Your storage array connection may be dropped under heavy IO when ATS heartbeat of 8 seconds times out, that will cause IO timeout in VM, causing Exchange to BSoD.

Secondary solution is to add storage controllers to VM and distribute database disks between controllers. In my case, single pvscsi controller would choke badly under 6 databases, but when disks (including OS disk etc) were distributed over 4 pvscsi controllers, issues disappeared. I don't have a reference for that, just personal experience on vSphere 5.5 U3.

answered on Server Fault May 28, 2016 by Don Zoomik • edited May 28, 2016 by Don Zoomik
4

What is wrong with this implementation of bitwise multiplication?

java
bit-manipulation

You are reading the binary string the wrong way round.

Try this...

public static int multiplyPolynomials(int n, int m) {
    int result = 0x00000000;
    String ns = Integer.toBinaryString(n);

    for (int i = 0; i < ns.length(); i++) {
        // Read the string the other way round...
        int bitIndex = (ns.length() - i) - 1;
        if (ns.charAt(bitIndex) == '1') {
            /*
             * If there's a 1 at place i, add the value of m left-shifted i
             * places to the result.
             */
            int temp = m;
            // Don't need a loop here, just shift it by "i" places
            temp = temp << i;
            result += temp;
        }
    }
    return result;
}

Instead of turning the number into a binary string, you could use something like this instead...

public static int multiplyPolynomials(int n, int m) {
    int result = 0x00000000;

    for (int i = 0; i < 32; i++) {
        int mask = 1 << i;

        if ((n & mask) == mask) {
            result += m << i;
        }
    }
    return result;
}

You might need to store your answer as a long to prevent overflows and it probably won't work too well with negative numbers...

answered on Stack Overflow Nov 17, 2016 by BretC • edited Nov 17, 2016 by BretC
3

What's happening in the background of a unsigned char to integer type cast?

c++
binary
casting
implicit-conversion

The sign of your (signed) char got extended to form a signed int. That is because of the way signed values are stored in binary.

Example

1 in binary char = 00000001

1 in binary int = 00000000 00000000 00000000 00000001

-1 in binary char = 11111111

-1 in binary int is NOT 00000000 00000000 00000000 11111111 but 11111111 11111111 11111111 11111111

if you convert back to decimal you should know up front whether you are dealing with signed or unsigned values because 11111111 might be -1 in signed and 255 in unsigned.

answered on Stack Overflow Jun 6, 2011 by Joris Mans
3

What's happening in the background of a unsigned char to integer type cast?

c++
binary
casting
implicit-conversion

char must be signed on your platform, and what you are seeing is sign extension.

answered on Stack Overflow Jun 6, 2011 by jason
2

Exchange 2016 on Windows Server 2012 BSoD

exchange
vmware-esxi
windows-server-2012-r2
exchange-2016

You can issue a command to disable the ESE forced reboot, the cause is well explained by Don's answer.

I did it latelly for a custumer with a single server with esx, as the IO was overkilling the Exchange. (its still killing it, as it take age to simply open a management console in example, but atleast it dont reboot..)

Add-GlobalMonitoringOverride -Identity ExchangeActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion “15.0.712.24

In there you need to use the correct Exchange version.

See there for Exchange version; https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

See there for furter detail; http://www.tecfused.com/2014/11/exchange-2013-dag-bsod/

answered on Server Fault May 28, 2016 by yagmoth555
2

What steps are required to debug a memory.dmp? (walkthrough included)

exchange-2013
debugging
dump
bsod
windbg
  1. No. Dumps can be analyzed offline (just like you did).
  2. Yes, assuming you've got the symbol server setting correct.
  3. Yes, that is the address of the PEB of the failing process. The process name is given in your analysis. You can get the complete PEB by typing !PEB 0xffffe0018668f080 in Windbg. The image name and process name are confusing to me though. The exchange process has crashed the wininit process but I would not expect both names in the PEB. Perhaps someone with more knowledge can chime in to clear (my) misunderstanding of things.
  4. I have no idea where that comes from. Never seen that before.
  5. Also no idea
  6. Nothing afaik. You have done all the steps needed to find the culprit
  7. Use your favorite search engine to try and find similar events. Searching on msexchangerepl and winit finds following possible relevant link:Exchange and BugChecks. Exchange apparently crashes wininit intentionally when writing to the event log fails for a long period of time.

The hung IO detection feature in Exchange 2010 is designed to make recovery from hung IO or a hung controller fast, rather than re-trying or waiting until the storage stack raises an error that causes failover. It’s a great addition to the set of high availability features built into Exchange 2010.

answered on Server Fault Aug 27, 2015 by Lieven Keersmaekers
2

Signed/Unsigned int, short and char

c
printf
integer-promotion

why has the sign extension taken place while printing s and c

Let's see the following code:

unsigned char ucr8bit; /* Range is 0 to 255 on my machine */
signed char cr8bit; /* Range is -128 to 127 on my machine */
int i32bit;
cr8bit = MINUS_100;  /* (char)(-100) or 0x9C */
i32bit = cr8bit;     /* i32 bit is -100 or 0xFFFFFF9C */

As you can see, althout the number -100 is same, its representation is not mere prepending 0s in wider character but may be prepending the MSB or sign bit of the signed type in 2s complement system and 1s complement system.

In your example you are trying to print s and c as wider type and hence getting the sign bit replication.


Also your code contains many sources of undefined and unspecified behavior and thus may give different output on different compilers. (For instance, you should use signed char instead of char as char may behave as unsigned char on some implementation and as signed char on some other implmentations)

l = 0xdeadbeef; /* Initializing l from an unsigned
                   if sizeof l is 32 bit UB as l is signed */
s = l;  /* Initializing with an undefined value. Moreover
           implicit conversion wider to narrower type */
printf("l = 0x%x (%d bits)\n", l, sizeof(l) * 8);  /* Using %x
               to print signed number and %d to print size_t */
answered on Stack Overflow Jan 19, 2015 by Mohit Jain • edited Jan 19, 2015 by Mohit Jain
2

What's happening in the background of a unsigned char to integer type cast?

c++
binary
casting
implicit-conversion

What hasn't been stated yet (as I type, anyway) is that it is unspecified whether or not char is singed. In your case - as was stated - char is signed, so any ASCII value above 127 is going to be interpreted as a negative.

answered on Stack Overflow Jun 6, 2011 by John
1

Signed/Unsigned int, short and char

c
printf
integer-promotion

You are using a 32-bit signed integer. That means that only 31 bits can be used for positive numbers. 0xdeadbeef uses 32 bits. Therefore, assigning it to a 32-bit signed integer makes it a negative number.

When shown with an unsigned conversion specifier, %x, it looks like the negative number that it is (with the sign extension).

When copying it into a short or char, the property of it being a negative number is retained.

To further show this, try setting:

l = 0xef;

The output is now:

l = 0xef (32 bits)
s = 0xef (16 bits)
c = 0xffffffef (8 bits)

0xef uses 8 bits which is positive when placed into a 32-bit or 16-bit variable. When you place an 8-bit number into a signed 8-bit variable (char), you are creating a negative number.

To see the retention of the negative number, try the reverse:

c = 0xef;
s = c;
l = c;

The output is:

l = 0xffffffef (32 bits)
s = 0xffffffef (16 bits)
c = 0xffffffef (8 bits)
answered on Stack Overflow Feb 27, 2015 by Jumbo
1

What's happening in the background of a unsigned char to integer type cast?

c++
binary
casting
implicit-conversion

Sign extension

answered on Stack Overflow Jun 6, 2011 by ildjarn
1

What's happening in the background of a unsigned char to integer type cast?

c++
binary
casting
implicit-conversion

"Can someone briefly explain what was going on in the char -> int promotion that produced 0xffffffef instead of 0x000000ef?"

Contrary to the four answers so far, it didn't.

Rather, you had a negative char value, which as a switch condition was promoted to the same negative int value as required by

C++98 §6.4.2/2
Integral promotions are performed.

Then with your 32-bit C++ compiler 0xffffffef was interpreted as an unsigned int literal, because it’s too large for a 32-bit int, by

C++98 2.13.1/2
If it is octal or hexadecimal and has no suffix, it has the first of these types in which it can be represented: int, unsigned int, long int, unsigned long int.

Now, for the case label,

C++98 §6.4.2/2
The integral constant-expression (5.19) is implicitly converted to the promoted type of the switch condition.

In your case, with signed destination type, the result of the conversion is formally implementation-defined, by

C++98 §4.7/3
If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.

But in practice nearly all compilers use two's complement representation with no trapping, and so the implementation defined conversion is in your case that the bitpattern 0xffffffef is interpreted as two's complement specification of a negative value. You can calculate which value by 0xffffffef - 232, because we’re talking 32-bit representation here. Or, since this is just an 8-bit value that’s been sign extended to 32 bits, you can alternatively calculate it as 0xef - 28, where 0xef is the character code point.

Cheers & hth.,

answered on Stack Overflow Jun 6, 2011 by Cheers and hth. - Alf • edited Jun 7, 2011 by Cheers and hth. - Alf
0

Projection matrix causing inaccuracy in clip-space depth calculation?

c#
directx
direct3d
hlsl
slimdx

Your depth buffer always has the same value written into it because you have your projection matrix wrong. The value that actually gets written is the w-value so you need to juggle your matrix around a bit.

The DirectX documentation gives a good explanation of the perspective transform.

Basically your matrix should be as follows

W, 0, 0, 0
0, H, 0, 0
0, 0, Q, 1
0, 0, P, 0

Where

W = 1.0f / tanf( fovHoriz / 2 );
H = 1.0f / tanf( fovVert  / 2 );
Q = zFar / (zFar - zNear);
P = -Q * zNear;
answered on Stack Overflow May 20, 2013 by Goz • edited May 23, 2017 by Community

Comments

Leave a comment

(plain text only)

Sources

  1. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2
  2. https://msdn.microsoft.com/en-us/library/cc231198.aspx
  3. winerror.h from Windows SDK 10.0.14393.0

User contributions licensed under CC BY-SA 3.0