ASService ImageLoad Publish Model problem

stefanp2 Hi!

I'd treat this as a resource/concurrency issue rather than an ImageLoad bug. The ImageLoad step is just where PBIRS streams the refreshed model into the embedded Analysis Services engine — and when 4 refreshes hit your 8 cores at once, the engine gets so busy that the connection to it drops mid-stream. That's why it dies right at "publish model." The ImageLoad message is the victim, not the cause.

A few thoughts on your questions:

• Biggest fix: don't run all 4 refreshes at the same time. Just stagger them a few minutes apart. Cheap, and it usually makes the whole thing go away.
• MaxQueueThreads is a valid lever — 2–3 isn't really "too low." It only caps the scheduled queue, not on-demand reports, so users won't notice. I'd stagger the schedules first and set it to 2 as a safety net.
• Watch memory, not just CPU. During refresh the engine holds roughly 2× the model size, so 4 at once can hit the memory ceiling and fail the same way. Make sure you've got RAM headroom, and give the PBIRS service account the "Lock pages in memory" right. Optimizing the heaviest models (push calc columns to Power Query/source, drop unused columns) also shrinks the spike.
• Auto-retry is fine as a backstop, but I wouldn't lead with it — fix the concurrency first.
• Those D:\a\_work\1\s\Sql\Rosetta\... paths — ignore them. They're just Microsoft's build-machine paths compiled into the binaries. Nothing on your server, nothing to configure.
• "Failed to create dump file" is a side effect, not a separate bug — the engine was too wedged to dump itself. It stops once you relieve the pressure.

So: stagger the schedules → set MaxQueueThreads to 2 → check RAM → trim the heaviest models. If it still happens after that, it's probably time for more RAM/cores or a support ticket.

Hope it helps!

💡 Did I answer your question? Mark my post as a solution!

👍 Kudos are appreciated

🔥 Proud to be a Super User!