This is an upstream (aqbanking) problem (maybe in connection with KMyMoney). Here's the aqbanking log that shows in the above scenario:

5:2013/07/01 14-46-38:(null)(13414):dlg_setup.c: 1049: Activated: userListBox
5:2013/07/01 14-46-38:(null)(13414):dlg_setup.c: 1049: Activated: accountListBox
5:2013/07/01 14-46-46:(null)(13414):dlg_setup.c: 1049: Activated: addAccountButton
5:2013/07/01 14-46-49:(null)(13414):dlg_selectbackend.c:  333: Activated: backendCombo
5:2013/07/01 14-46-58:(null)(13414):dlg_selectbackend.c:  333: Activated: okButton
3:2013/07/01 14-46-58:aqbanking(13414):dlg_setup.c:  920: Could not create dialog

This needs to be investigated further.

Is this still relevant, or should we mark it as upstream?

The bug also exists in 4.6.4. Please mark it as upstream.

Did you send this bug to the aqbanking mailing list?

I have exactly the same problem. Did somebody find a way around this? Is anybody using kmymoney with hbci and stuff?

I have this issue from time to time. Usually it is caused by some missing plugins or incorrect paths (there are many in aqbanking). Maybe the package was defect.

Same issue here with 4.8.0 on Linux and Windows.

backtrace is 
#0  AB_SetupDialog_AddAccount (dlg=dlg@entry=0x5e63c60) at dlg_setup.c:894
#1  0x62e4a3b5 in AB_SetupDialog_HandleActivated (dlg=0x5e63c60, sender=0x9ad56d0 "addAccountButton") at dlg_setup.c:1061
#2  0x62d8edc3 in GWEN_Dialog_EmitSignal (dlg=0x5e63c60, t=GWEN_DialogEvent_TypeActivated, sender=0x9ad56d0 "addAccountButton") at dialog.c:
#3  0x6f18180e in QT4_DialogBox::slotActivated (this=0x9ad4bf0) at qt4dialogbox.cpp:117

Tracing the dialog creation in

int AB_SetupDialog_AddAccount(GWEN_DIALOG *dlg) {
  AB_SETUP_DIALOG *xdlg;
  AB_PROVIDER *pro;
  const char *s;
  const char *initialProvider=NULL;
  uint32_t flags;

  assert(dlg);
  xdlg=GWEN_INHERIT_GETDATA(GWEN_DIALOG, AB_SETUP_DIALOG, dlg);
  assert(xdlg);

  s=GWEN_I18N_GetCurrentLocale();
  if (s && *s) {
    if (strstr(s, "de_"))
      initialProvider="aqhbci";
    else
      initialProvider="aqofxconnect";
  }
  pro=AB_SelectBackend(xdlg->banking,
		       initialProvider,
		       I18N("Please select the online banking backend the new "
			    "account is to be created for."));
  if (pro==NULL) {
    DBG_ERROR(0, "No provider selected.");
    return GWEN_DialogEvent_ResultHandled;
  }

gives 

(gdb) p *pro
$9 = {INHERIT__list = 0x5de1968, _list1_element = 0x5de2450, banking = 0x53db618, name = 0x5dc99b8 "AQHBCI", escName = 0x5dc9aa0 "aqhbci",
  initFn = 0x705e0b30 <AH_Provider_Init>, finiFn = 0x705e09d0 <AH_Provider_Fini>, updateJobFn = 0x705e0730 <AH_Provider_UpdateJob>, addJobFn
  executeFn = 0x705de680 <AH_Provider_Execute>, resetQueueFn = 0x705e1650 <AH_Provider_ResetQueue>, extendUserFn = 0x705de660 <AH_Provider_E
  extendAccountFn = 0x705de640 <AH_Provider_ExtendAccount>, updateFn = 0x705e11c0 <AH_Provider_Update>, getNewUserDialogFn = 0x705de080 <AH_
  getEditUserDialogFn = 0x705ddef0 <AH_Provider_GetEditUserDialog>, getNewAccountDialogFn = 0x0, getEditAccountDialogFn = 0x705e0f80 <AH_Provider_GetEditAccountDialog>, getUserTypeDialogFn = 0x705e10b0 <AH_Provider_GetUserTypeDialog>, plugin = 0x0, usage = 1, flags = 27, isInit = 1}


  flags=AB_Provider_GetFlags(pro);
  if (flags & AB_PROVIDER_FLAGS_HAS_EDITACCOUNT_DIALOG) {          

here value 27 & 8 --> true

    GWEN_DIALOG *dlg2;
    int rv;

    dlg2=AB_Provider_GetNewAccountDialog(pro);                      

-> dlg2 is zero because getNewAccountDialogFn is zero as shown in 'p *pro' above

    if (dlg2==NULL) {
      DBG_ERROR(AQBANKING_LOGDOMAIN, "Could not create dialog");

--> this message has been printed

      return GWEN_DialogEvent_ResultHandled;
    }

    rv=GWEN_Gui_ExecDialog(dlg2, 0);
    if (rv==0) {
      /* rejected */
      GWEN_Dialog_free(dlg2);
      return GWEN_DialogEvent_ResultHandled;
    }

It looks to be a mismatch to check AB_PROVIDER_FLAGS_HAS_EDITACCOUNT_DIALOG and then to use the address of GetNewAccountDialog().

Reported upstream with patch at https://git.aqbanking.de/trac/aqbanking/ticket/292

This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.