The most common crash cause is equipment corruption. Since I've suffered from it myself without any raiding (or even ability to raid, due to the playing of a dead civ), I know raiding isn't the only cause.
It's unclear from the description if the check was done correctly, as it's not a matter of looking at what militia is equipped with, but checking what the game think they could be equipped with. Looking for that in a vanilla game involved bringing up any squad member and check the specific equipment list for each category of equipment (boots, helmet, weapon, etc.). Corrupted equipment is show as nonsensical items in one or more of those list. Typically those items are "books" that sit at the end or near the end of lists.
Using DFHack (which is included with the LNP), this script can detect and possibly correct corruption:
function fix_equipment ()
local categories =
{{"FLASK", df.item_flaskst},
{"WEAPON", df.item_weaponst},
{"ARMOR", df.item_armorst},
{"SHOES", df.item_shoesst},
{"SHIELD", df.item_shieldst},
{"HELM", df.item_helmst},
{"GLOVES", df.item_glovesst},
{"AMMO", df.item_ammost},
{"PANTS", df.item_pantsst},
{"BACKPACK", df.item_backpackst},
{"QUIVER", df.item_quiverst}}
for i, element in ipairs (categories) do
for k = #df.global.ui.equipment.items_unassigned [element [1]] - 1, 0, -1 do
if df.global.ui.equipment.items_unassigned [element [1]] [k]._type ~= element [2] then
dfhack.printerr ("Corrupted unassigned " .. element [1] .. ", removing", k)
df.global.ui.equipment.items_unassigned [element [1]]:erase (k)
end
end
end
for i, element in ipairs (categories) do
for k = #df.global.ui.equipment.items_assigned [element [1]] - 1, 0, -1 do
if df.global.ui.equipment.items_assigned [element [1]] [k]._type ~= element [2] then
dfhack.printerr ("Corrupted assigned " .. element [1] .. ", removing", k)
df.global.ui.equipment.items_assigned [element [1]]:erase (k)
end
end
end
for i, squad in ipairs (df.global.world.squads.all) do
if squad.entity_id == df.global.ui.group_id then
local squad_name = dfhack.TranslateName (squad.name, true)
if squad.alias ~= "" then
squad_name = squad.alias
end
-- dfhack.println (squad_name, i)
for k, position in ipairs (squad.positions) do
for l, item_id in ipairs (position.assigned_items) do
local legal_type_found = false
local item = df.item.find (item_id)
if not item then
dfhack.printerr ("Nonexistent item assigned to squad member " .. tostring (k) .. " of squad " .. squad_name ..
". Detection only. No action performed.")
else
for m, element in ipairs (categories) do
if item._type == element [2] then
legal_type_found = true
break
end
end
if not legal_type_found then
dfhack.printerr ("Item " .. tostring (l) .. " assigned to squad member " .. tostring (k) .. " of squad " .. squad_name ..
" is of unexpected type " .. tostring (item._type) .. ". Detection only. No action performed.")
end
end
end
end
end
end
end
fix_equipment ()
In at least one case purged lists became corrupted again a month or so later, resulting in the need for an additional sweep.
Another known cause of crashes is weres giving birth to the "non existent" gender while turned (weres have only one gender, so when the game tries to assign the second one it crashes).
There's also a zero size critter bug, where DF generates critters (often baby ones) of a size that gets rounded/truncated to an integer size of 0. These critters can apparently exist causing no harm, but if they happen to get involved in some calculations in DF the game crashes (division by zero is not a good thing).
There are additional reasons for crashing, but many cases don't have any identified cause.
I'd suggest uploading the save to DFFD
https://dffd.bay12games.com/ and filing a bug report on the bug tracker
https://www.bay12games.com/dwarves/mantisbt/login_page.php.