Windows error 0x0000012B, 299

Detailed Error Information

PARTIAL_COPY[1]

MessageOnly part of a ReadProcessMemory or WriteProcessMemory request was completed.
Declared inwinerror.h

This appears to be a raw Win32 error. More information may be available in error 0x8007012B.

FAULTY_HARDWARE_CORRUPTED_PAGE[2]

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

HRESULT analysis[3]

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[3][1]
DescriptionThe default facility code.[3][1]
Error Code299 (0x012b)

Possible solutions

3

Failed to create assembly 'System.ServiceModel.Internals' in SQL

c#
clr
.net-assembly
sqlclr

Have you tried installing the assembly with the UNSAFE permission set option?

I have System.ServiceModel.Internals (v4 from GAC) installed on SQL Server 11.0.5058 as UNSAFE, I don't know if you will be having versioning issues as well but I believe the assembly can only be installed as unsafe as it may access unmanaged resources.

From your error message:

[found unmanaged pointer] [expected unmanaged pointer] Unexpected type on the stack.

I understand this as Expected Unmanaged pointer, found unmanaged pointer, unmanaged pointer not allowed.

See https://msdn.microsoft.com/en-us/library/ms189566.aspx for definitions of permission sets.

answered on Stack Overflow Feb 4, 2015 by Dave Manning
2

Failed to create assembly 'System.ServiceModel.Internals' in SQL

c#
clr
.net-assembly
sqlclr
  [found ref 'System.String'] Expected numeric type on the stack

The stack trace tells the tale, the CLR verifier checked the stack and found an unexpected type, a string instead of a number. That's pretty bad. The relevant method that's executing, the stack trace is not complete so we can't trace it all the way back, is System.Runtime.Diagnostics.DiagnosticsEventProvider.WriteTransferEvent().

This is a .NET 4 addition in the .NET Framework, it supports ETW (Event Tracing for Windows). A disassembler can show what code uses it, through several layers, that for example the System.ServiceModel.Channels.HttpRequestContext.TraceHttpMessageReceived() calls it.

In other words, we are firmly in WCF land, it received a message over HTTP and it generates an ETW event so it can be traced by ETW tooling. The call originated in System.ServiceModel.dll, the core WCF assembly, the ETW tracing code is located in System.ServiceModel.Internals.dll.

So, somehow, and it is getting to be a bit of a foregone conclusion how this could have happened given the nature of the question, the SQL Server machine has two different revisions of these WCF assemblies. They are normally distributed as a pair, part of the basic .NET install. There have been many revisions since .NET 4.0 RTM, versions 4.01, 4.02, 4.03 were slip-streamed through Windows Update for example, these updates in particular affected System.ServiceModel. Not to speak of versions 4.5, 4.5.1, 4.5.2 and 4.6 shipped since then and a few handfuls of KB updates that fixed bugs and patched security problems.

Anticipating the next question: so what's the correct revision of System.ServiceModel.Internals.dll? You can call Microsoft Support and they will tell you: "there isn't one". But you already knew that. So don't do this. If you want to try to make this working anyway then a basic strategy is to first look at the revision number of System.ServiceModel, then try to find a System.ServiceModel.Internals whose revision number is, if not equal, then at least in the ballpark. The one you have now is almost certainly not close, revision 34234 is, roughly, a .NET 4.5.2 revision number.

answered on Stack Overflow Feb 1, 2015 by Hans Passant
1

Hex vs. decimal representation of numbers in registers and operands

assembly
x86

The numbers has no "numeral system" at all. They have only value.

The numeral system (hexadecimal, decimal, octal, binary, etc) is only a writing system. It has meaning only if the number has to be written on some information carrier - sheet of paper, computer screen, memory cell, etc.

Changing the numeral system, does not change the value of the number.

So, you can write the number in different numeral systems and it will have the same value, regardless that it seems to be different. You only need to read it differently.

In assembly language, the hexadecimal system is preferred because it allows very easy (mentally) converting to and from binary (the system CPU use to write numbers in the memory). That is why most debuggers will display the numbers in hex.

answered on Stack Overflow Dec 16, 2016 by johnfound
0

C# SearchByte Array inside Process Memory

c#
.net
pinvoke
readprocessmemory

Oooooooook I solved it. The problem was the way I was trying to read it without using VirtualQueryEx and checking for the memory region protection!

answered on Stack Overflow May 3, 2013 by Tommaso Belluzzo

Comments

Leave a comment

(plain text only)

Sources

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

User contributions licensed under CC BY-SA 3.0