The debugger message already gives a hint. The short version: You must Lock() the BBitmap before even adding the child view, and then Unlock() after syncing and removing the view from the bitmap. The long version: BViews live in a multi-threaded programming environment. To help the developer, there is active debugging code in libbe.so BView code which checks for locking errors. Effectively, any invokation of a BView method requires the BWindow that the BView is part of to be locked. When a BView is added to a BBitmap, it is in fact added to a "dummy" BWindow object owned by the BBitmap, which is used for dispatching drawing commands to the app_server. This window, even though the client thread never actually runs, still needs to be locked, since the BView locking checks should not be even more complicated than they already are. And of course the locking checks would still point out invalid concurrent access in your client app, regardless of whether the client window thread runs or not. To complete the picture about locking, perhaps the added information that when you are running code in your window thread, the window is always already locked, since you will always come from within the message dispatching code, which locks the window. Best regards, -Stephan Great explanation, thank you too, Stephan!