Problem

When there is field data in place, there is a de-facto dependency of the field system as a whole on field type modules - if that module is disabled, it is has no idea what to do with the data until the module is re-enabled again (and other actions while the module is disabled, like deleting bundles or instances can complicate this too).

The patch in #943772 uses hook_system_info_alter() to make this dependency explicit - i.e. by making those field type modules required in the UI, with an explanatory note.

With the proposed solution, a module which both defines and implements a field type can not delete its fields on uninstall. Therefore, the solution is "Don't do that." Instead, the field type should be defined in a helper module which the implementation module depends on.

For example:

1. foo_field.module implements hook_field_info() to define a field type foo_type.
2. foo.module depends on foo_field.module.
3. When a user installs foo.module, foo_install() calls field_create_field(array('field_name' => 'foo', 'field_type' => 'foo_type')).
4. When the user uninstalls foo.module, foo_uninstall() calls field_delete_field('foo'), and its fields are marked for deletion.
5. The field values get purged on subsequent cron runs.
6. After the purge is completed, the user can uninstall foo_field.module.

See the full API Change node at Field types should be defined by one module and implemented by a separate module..

Solution

If you which to disable the culprit module you either wait for an update which fulfill the API Change Field types should be defined by one module and implemented by a separate module. Either you delete the culprit field info in the field_config table.