Windows error 0x00000066, 102

Detailed Error Information

SEM_IS_SET[1]

MessageThe semaphore is set and cannot be closed.
Declared inwinerror.h

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

CACHE_INITIALIZATION_FAILED[2]

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

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 Code102 (0x0066)

Possible solutions

3

Simple encryption Assembly Program - Access violation writing to memory location

c++
assembly
encryption
cdecl

By inspection, the comment on the encrypt function is wrong. Remember: the stack grows down, so when the arguments are pushed onto the stack, the ones pushed first have the higher address and, therefore, the higher offset from the base pointer in the stack frame.

The comment to encrypt says:

// Inputs: register EAX = 32-bit address of Ekey,
//                  ECX = the character to be encrypted

However, your calling sequence is:

movzx  eax, temp_char    ; push the char to encrypt FIRST
push   eax
lea    eax, EKey         ; push the encryption key SECOND
push   eax
call   encrypt

So the character is push first. So the character to encrypt But encrypt is loading them this way:

; On function entry, the old Instruction Pointer (4 bytes) is pushed onto the stack
; so now the EKey is +4 bytes from the stack pointer
; and the character is +8 bytes from the stack pointer
;

push ebp
mov ebp, esp

; We just pushed another 4 bytes onto the stack (the esp register)
; and THEN we put the stack pointer (esp) into ebp as base pointer
; to the stack frame.
;
; That means EKey is now +8 bytes off of the base pointer
; and the char to encrypt is +12 off of the base pointer
;
mov ecx, 8[ebp]            ; This loads EKey pointer to ECX
mov eax, 12[ebp]           ; This loads char-to-encrypt to EAX

The code then proceeds to try to reference EAX as a pointer (since it thinks that's EKey), which is going to cause an access violation since it's your character to encrypt the first time it tries to reference EAX as a pointer, which is here:

not byte ptr[eax]

So your debugger pointer was right! :)

You can fix it just by swapping these two registers:

mov eax, 8[ebp]            ; This loads EKey pointer to EAX
mov ecx, 12[ebp]           ; This loads char-to-encrypt to ECX

Finally, your call to encrypt doesn't clean up the stack pointer when it's done. Since you pushed 8 bytes of data onto the stack before calling encrypt, and since encrypt does a standard ret with no stack clean-up, you need to clean up after the call:

...
call   encrypt
add    esp, 8
...
answered on Stack Overflow Mar 19, 2015 by lurker • edited Mar 19, 2015 by lurker
1

Problem creating COM-library only containing enum's

.net
com
interop
com-interop
idl

To answer your last question first. What you are wanting is a TypeLib not a COM library. Where a COM interface is a bunch of code and function pointers, a TypeLib is the map for interacting with those pointers (along with defines and enums and a bunch of other stuff). Only when they come together is there a COM library. Since there is no COM interface, you cannot have a COM library.

Microsoft has provided an example on how to create a TypeLib without an interface. It is a very similar to the one you have described. As you'll notice, there's no COM interface in it; and because of this, it has to stay a lowly TypeLib.

The next problem is the .NET assembly. When you use TlbImp.exe to import the enums into your code, that allows you to use those enums within your code - inside your assembly. That is the limit of what you can do with the enums. You cannot export those enums because they don't belong to your .NET code. The enum is owned by the TypeLib. Your .NET code has permission to use the enum, but it cannot claim to own the enum.

Finally, to answer your first question. You need to use the features provided with .NET. It has the ability to define enums and export them and make them visible from COM. While I understand the frustration over naming convention, this is not something that you should try to work around or bypass. As you have seen, attempting to bypass this minor problem with the naming convention has caused major problems, effectively making your new code unusable.

answered on Stack Overflow Aug 6, 2011 by jveazey
1

Problem creating COM-library only containing enum's

.net
com
interop
com-interop
idl

I have done this:

In .NET, I created a COM visible library named PermissionControlLib with an enum like this:

public enum NetOperations
{
   Oper1,
   Oper2,
   Oper3
}

In VB6, I've created another enum like this:

Public Enum VBOperations
   Oper1=NetOperations.NetOperations_Oper1,
   Oper2=NetOperations.NetOperations_Oper2,
   Oper3=NetOperations.NetOperations_Oper3
End Enum

Usage:

Dim ud as PermissionControlLib.IUser
Set ud = New User
Dim b as Boolean
b = ud.HasPermissionInOperation(VbOperations.Oper1)
answered on Stack Overflow Oct 14, 2013 by user1780087
0

C++ Error when changing the cursor from a resource file

c++
cursor
loadimage
ntdll
resource-file

When calling LoadImage(), you are specifying the LR_LOADFROMFILE flag, so the lpszName parameter will be interpreted as a pointer to a null-terminated string containing the path to the .cur file to load. But, you are passing in a resource ID number instead of a file path string (I'm assuming IDC_CURSOR1 is 102 (0x66), which would be consistent with the memory address reported in the error message). You need to get rid of the LR_LOADFROMFILE flag when loading an image from resources.

Also, you need to pass in the EXE's actual module handle in the hinst parameter, not NULL (NULL can only be used with loading OEM-defined images).

Also. you should not be using "magic numbers". The 2 on LoadImage() should be replaced with the IMAGE_CURSOR constant, and the 32512 on SetSystemCursor() should be replaced with the OCR_NORMAL constant.

Try this:

HCURSOR curs = (HCURSOR) LoadImage(GetModuleHandle(), MAKEINTRESOURCE(IDC_CURSOR1), IMAGE_CURSOR, 0, 0, 0);
SetSystemCursor(curs, OCR_NORMAL);
answered on Stack Overflow Jun 13, 2018 by Remy Lebeau • edited Jun 13, 2018 by Remy Lebeau
0

Huge amount of mystic crashes of WP8 app

windows-phone-8

Are you sure you're handling the Disconnect callback accordingly ? As in do you clear and reload all your resources after a Surface::Diconnect ? If you do not handle Disconnect at all, your app will crash on resume. If you do handle it and you're not doing it the proper way your app will start using more and more memory and will crash if it goes past 170MB or so.

answered on Stack Overflow Jan 28, 2015 by RelativeGames
0

Integration of IE9 in Vista SP2 fails with error 0x8007000e

windows-vista
internet-explorer-9
unattended

Error 0x8007000e is due to lack of memory. Upgrading from 1GB to 2GB resolved the issue.

answered on Super User Apr 7, 2014 by Velcro

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