Windows error 0x00000088, 136

Detailed Error Information


MessageThe system tried to delete the JOIN of a drive that is not joined.
Declared inwinerror.h

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

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.

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
Reserved (X)false
FacilityCode0 (0x000)
DescriptionThe default facility code.[2][1]
Error Code136 (0x0088)

Possible solutions


Win8 - Unhandled exception in Windows.UI.Xaml.dll


If you're passing objects implemented INotifyPropertyChanged, inherited BindableBase or DependencyObject etc. thru NavigationParameter; and bind then in the NavigatedPage (or binded them in the navigating page) you'll most likely get this error. Don't pass any object except primitive type thru NavigationParameter when navigating.

You are getting this exception because non-existent referenced methods. For example.

  1. You have an object named Categories which inherites BindableBase.
  2. You binded that to Home.xaml.
  3. Home.xaml's binding mechanism subscribed the PropertyChanged event of Categories object.
  4. You navigated the Article.xaml passing Categories object as a the NavigationParameter.
  5. You binded the Categories object to Article.xaml.
  6. When a property changes in Categories object; that property will fire PropertyChanged event.
  7. There are two subscribers to that event. Home.xaml and Article.xaml, but Home.xaml is no longer exist since you navigated away from it. But your delegate holds the address of it; so it tries to Execute; and fail with Access violation error.
answered on Stack Overflow Sep 28, 2012 by Medeni Baykal

What exactly does the lb instruction do?


The answer would be c) 0xffffff88. The lb instructions sign-extends the byte into a 32-bit value. I.e. the most significant bit (msb) is copied into the upper 24 bits.

0x88 == 0b10001000, i.e. the msb is 1. So the upper 24 bits will be 0b111111111111111111111111 == 0xffffff.

answered on Stack Overflow Feb 12, 2013 by Michael

What exactly does the lb instruction do?


The lb instruction loads a byte from memory and sign extends to the size of the register. The lbu instruction does the same without sign extension (unsigned).

Most computers, MIPS included, use two's complement to represent signed values though there are other ways to encode the sign, floating point is usually represented in IEEE 754 format which uses signed magnitude. An integer signed value can be represented in any number of bits, for example

  • a char in C is 8-bits and can represent -128 to +127
  • a short in C is 16-bits and can represent -32768 to +32767
  • etc

In two's complement the most significant bit can be used to determine the sign of the number, a '1' means it is negative, and a '0' means it is positive.

The number 0x88, when interpreted as an 8-bit two's complement number is negative 0x78 or -120 decimal. When represented in 32-bits two's complement this is 0xFFFFFF88. There are a couple of ways to remember how to compute the two's complement of a number:

  • take the one's complement of the number (invert every bit) and add '1', or
  • go from least significant bit towards most significant bit (right to left), skip over every '0' and the first '1' you encounter, invert every bit after that

To sign extend a 8-bit to 32-bits just look at the most significant bit (bit 7) and copy that bit to bits 8 thru 31... This follows from the definition of two's complement.

answered on Stack Overflow Feb 12, 2013 by amdn • edited Feb 12, 2013 by amdn

signed and unsigned representation of data in memory?


There is no need to guess about how things are represented in memory, and 2's complement arithmetic is endianness-agnostic.

Consider the following program.

#include <stdio.h>

int main(){
    signed int a = 136; 
    unsigned int b = -120; 

    unsigned sum = a + b;
    printf("a = 0x%x b = 0x%x sum = 0x%x\n", a,b, sum);


a = 0x88 b = 0xffffff88 sum = 0x10

In 2's complement, when we can sum a and b in binary without worrying about signs.

When we do the sum by hand, we will get a + b = 0x100000010. Since the first 1 overflows, it is simply dropped, leaving us 0x10, which is 16.

answered on Stack Overflow Jun 5, 2014 by merlin2011

Why are my core dumps missing an NT_FILE note?


Why is there no NT_FILE note?

As noted by Mark Plotnick, it's a fairly recent kernel addition.

In no way NT_FILE note required for GDB (in fact, current GDB doesn't appear to use NT_FILE at all, except when writing a core file with gcore command).

How can I figure out the various object files the core file may be based on, and more importantly, the virtual addresses where those files were mapped into the core image?

The way this works for GDB is to look at PT_DYNAMIC for the main executable in the core, extract DT_DEBUG from that, which then gives it a pointer to _r_debug, which includes a linked list r_map of struct link_map, with each node in the list describing a loaded ELF file.

The (gdb) info shared command will show you the decoded version of above info, but you need to provide matching binaries: the core alone does not contain sufficient info.

Now, your question isn't very clear and could be understood several different ways.

It could be: "I have a core, which application crashed?" Use file core and hope that the first 16 characters of pathname are sufficient. If that isn't sufficient, running strings core will often reveal which application produced it. You should also consider setting /proc/sys/kernel/core_pattern to something that includes %e or %E, so the question is trivial to answer in the future.

It could be: "I have several versions of application foo, and want to know which version of foo produced this particular core". In that case, you should be linking foo with -Wl,--build-id linker flag. That flag creates NT_GNU_BUILD_ID note in the foo binary. That note survives strip, and is saved inside the core file as well. You can then run eu-unstrip -n --core /path/to/core, and that will produce output like this:

eu-unstrip -n --core core
0x400000+0x208000 c266a51e4b85b16ca17bff8328f3abeafb577b29@0x400284 - - [exe]
0x7ffe3f7d9000+0x1000 7f14688f101a2ace5cad23dfbfbc918616651576@0x7ffe3f7d9340 . -
0x7fb5b6ec3000+0x2241c8 d0f537904076d73f29e4a37341f8a449e2ef6cd0@0x7fb5b6ec31d8 /lib64/ /usr/lib/debug/lib/x86_64-linux-gnu/
0x7fb5b6afe000+0x3c42c0 cf699a15caae64f50311fc4655b86dc39a479789@0x7fb5b6afe280 /lib/x86_64-linux-gnu/ /usr/lib/debug/lib/x86_64-linux-gnu/

From above output, you can know both exactly which ELF binaries were used, and where in memory they were loaded.

P.S. I just tried dumping a core from a.out built with -Wl,--build-id=none, and the resulting eu-unstrip output is still quite useful:

eu-unstrip -n --core core
0x400000+0x202000 - - - [exe]
0x7fff5e1a0000+0x1000 7f14688f101a2ace5cad23dfbfbc918616651576@0x7fff5e1a0340 . -
0x7fbda432d000+0x2241c8 d0f537904076d73f29e4a37341f8a449e2ef6cd0@0x7fbda432d1d8 /lib64/ /usr/lib/debug/lib/x86_64-linux-gnu/
0x7fbda3f68000+0x3c42c0 cf699a15caae64f50311fc4655b86dc39a479789@0x7fbda3f68280 /lib/x86_64-linux-gnu/ /usr/lib/debug/lib/x86_64-linux-gnu/


There is no PT_DYNAMIC program header in my core file itself,

No, but PT_DYNAMIC is a writable segment @0x6006a0. That segment is actually written to (by the dynamic loader), and thus is always saved in the core (as other modified data).

In your case, the contents is in the PT_LOAD segment @0x600000 (i.e. the segment at file offset 0x2000 in the core).

answered on Stack Overflow Sep 30, 2016 by Employed Russian • edited Oct 1, 2016 by Employed Russian

C++, WIN32, WndProc to Member Function Crash (Access violation at 0x88)


I have some code from a custom dialog handler I wrote quite a while back, which might be of use to you.

Same principle applies for a window but switch the WM_INITDIALOG for WM_CREATE and also replace DWLP_USER with GWLP_USERDATA. The format of the callback is subtley different too. You should be able to salvage almost all of this function though.

LRESULT CALLBACK CDialog::DlgProc( HWND hWndDlg, UINT msg, WPARAM wParam, LPARAM lParam )
    CDialog* pWindow;

    if( msg == WM_INITDIALOG ) {
        SetWindowLongPtr( hWndDlg, DWLP_USER, (LONG_PTR)lParam );
        pWindow = reinterpret_cast<CDialog*>( lParam );
        pWindow->m_hWnd = hWndDlg;
    } else {
        pWindow = reinterpret_cast<CDialog*>( (LPARAM)GetWindowLongPtr( hWndDlg, DWLP_USER ) );

    if( pWindow != NULL ) {
        LRESULT ret = pWindow->OnMessage( msg, wParam, lParam );
        if( msg == WM_NCDESTROY ) pWindow->m_hWnd = NULL;

    return FALSE;
answered on Stack Overflow Mar 18, 2013 by paddy

uPP Device Driver is dropping data from buffer


In case you would like to submit the driver to upstream (which actually a right way to go), you probably may contact with TI guys who are working with DaVinci boards. I assume you already googled the link DaVinci Wiki.

Regarding to your driver it's hard to check due to its code style. Moreover you may check modern kernel APIs for stuff you are trying to program manually (voltage regulators, clocks, pin control, and so on). For many basic devices there are already drivers and setup. Also you have to describe you board configuration in device tree. Usually it means to create an additional (to the common) piece of configuration and put it under arch/arm/boot/dts/. There you may find da850 predefined data bases.

answered on Stack Overflow Jan 7, 2015 by 0andriy

signed and unsigned representation of data in memory?


your second binary representation is correct. adding this 2 binary numbers together you will get 0x10 in hex or 16 in decimal (and an overflow)

-120 in unsigned int will have the value 4 294 967 176 in 4 byte unsigned int

answered on Stack Overflow Jun 5, 2014 by mch

signed and unsigned representation of data in memory?

0xffffff88 +
0x00000010 => 16

Also 1 in front of the result is discarded.

The 1 in second to last position in the result is from the carry by adding 8 + 8.

answered on Stack Overflow Jun 5, 2014 by GeoAoe

DWARF - How to find the prologue end/epilogue start addresses of functions in a given binary?



readelf -wi

And look for DW_AT_low_pc and DW_AT_high_pc for the subroutine you are looking at.

The DWARF spec says:

A subroutine entry may have either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a DW_AT_ranges attribute whose values encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions generated for the subroutine (see Section 2.17).

If I remember correctly, the DW_AT_low_pc is the address immediately after the prologue and DW_AT_high_pc is the last address before the epilogue.

Don't worry about the opcodes being 'special' that just means that they don't take arguments to save space in the encoded line number program.

answered on Stack Overflow Sep 28, 2014 by Torleif

Stream from IP Camera very jittery on VLC


Because read is a blocking call, you should either manage non-blocking read or use a thread. But your kernel module doesn't seems to implement select/poll callback.

Then a first step could be to call the read outside from the live555 mainloop using an additionnal thread like this :

#include "DeviceSource.hh"
#include <GroupsockHelper.hh> // for "gettimeofday()"
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <pthread.h>

static uint8_t buf[131072];
int upp_stream; 
EventTriggerId DeviceSource::eventTriggerId = 0;
unsigned DeviceSource::referenceCount = 0;
pthread_t thid;
bool stop = false;

static void* thread(void* clientData) 
    DeviceSource* This = ((DeviceSource*)clientData);
    while (!stop) 
        if (This->isCurrentlyAwaitingData())
            ::read(upp_stream, buf, sizeof(buf));
            This->envir().taskScheduler().triggerEvent(DeviceSource::eventTriggerId, This);
    return NULL;

DeviceSource* DeviceSource::createNew(UsageEnvironment& env) { return new DeviceSource(env); }
DeviceSource::DeviceSource(UsageEnvironment& env):FramedSource(env) 
    if (referenceCount == 0) 
        upp_stream = open("/dev/upp",O_RDWR);
        pthread_create(&thid, NULL, thread, this);
        eventTriggerId = envir().taskScheduler().createEventTrigger(deliverFrame0);

DeviceSource::~DeviceSource(void) {
    if (referenceCount == 0) 
        pthread_join(thid, NULL);

        eventTriggerId = 0;

void DeviceSource::doGetNextFrame() {}

void DeviceSource::deliverFrame0(void* clientData) { ((DeviceSource*)clientData)->deliverFrame(); }
void DeviceSource::deliverFrame() 
    if (!isCurrentlyAwaitingData()) return; // we're not ready for the data yet
    //Bitwise Shift hex from buf[12] to buf[15] to get data count  
    unsigned int data_count2 = (buf[12] << 24)|(buf[13]<<16)|(buf[14]<<8)|buf[15];

    u_int8_t* newFrameDataStart = (uint8_t*)buf;
    unsigned newFrameSize = sizeof(buf);//f_size; 
    // Deliver the data here:
    if (newFrameSize > fMaxSize) 
        fFrameSize = fMaxSize;
        fNumTruncatedBytes = newFrameSize - fMaxSize;
        fFrameSize = newFrameSize;
    gettimeofday(&fPresentationTime, NULL); //chk this 
    memmove(fTo, newFrameDataStart, fFrameSize);

As you notice this simple sample doesnot read frame in background. This needs to implement a FIFO between the two threads.

It could be build using :

CPPFLAGS=-pthread LDFLAGS=-pthread make
answered on Stack Overflow Feb 1, 2015 by mpromonet • edited Feb 15, 2015 by mpromonet

Crashing during unlocking achievement


Where do you initialize your Google API client? Personally, to unlock an achievement I use this:

public void unlockAchievement(int id)
    Games.Achievements.unlock(mGoogleApiClient, AchievementIDs[id]);

"mGoogleApiClient" is initialized in OnCreate like so:

    mGoogleApiClient = new GoogleApiClient.Builder(this)

I hope this helps :)

answered on Stack Overflow Dec 17, 2014 by Scumble373


Leave a comment

(plain text only)


  1. winerror.h from Windows SDK 10.0.14393.0

User contributions licensed under CC BY-SA 3.0